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<TYPENAME>; FIRST LINE IN THE 
JTR FILE IS ENTERED AS TYPE 
<TYPENAME>. 



.FIR DEVELOPER DEFINES 
LOGICAL EXPRESSION WICH 
EVALUATES TO TRUE IFF FILE IS 
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IN MATCH-EXPRESSION LANGUAGE 
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DEVELOP .FIR FILE USING 
EDITOR OF DEVELOPER'S CHOICE 
(E.G. VI, ED, EX). 



COMPILE A .FIR FILE WITH ALL 
OTHER .FTR FILES INTO A .CTR 
RLE USING STANDARD COMPILING 
TECHNIQUES. 



STORE. CTR FILE IN DESIGNATED 
PLACE IN RLE SYSTEM. 



FIG. 2 



PROGRAMS CAN NOW USE THE 
.CTR FILE FOR TYPING FILES 
AFFECTING ICON BEHAVIOR. 
.FTR DEVELOPER CHOOSES A 

<TYPENAME>; FIRST UNE IN THE 
.FTR FILE ENTERED AS TYPE 
<TYPENAME>. 
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.FIR DEVELOPER CHOOSES A 
<TYPENAME>; FIRST LINE IN THE 
.FIR FILE IS ENTERED AS TYPE 
<TYPENAME>. 



.FIR DEVELOPER DEFINES 
LOGICAL EXPRESSION WHICH 
EVALUATES TO TRUE IFF RLE IS 
OF TYPE DECLARED BY THE TYPE 
STATEMENT. EXPRESSION IS WRITTEN 
IN MATCH-EXPRESSION LANGUAGE 
AND ENTERED IN .FIR FILE AFTER 
TYPE STATEMENT AS MATCH 4AATCH 
EXPRESSION* 



.FTR DEVELOPER DEFINES TEXT 

STRING IN PLAIN LANGUAGE 
WHICH USER CAN UNDERSTAND. 
TEXT STRING IS ENTERED INTO 

.FTR FILE AFTER MATCH 
STATEMENT ABOVE AS LEGEND 
<TEXT STRING>. 



FIG. 3A 



.FTR DEVELOPER CHOOSES TYPES 
TO WHICH THIS TYPE IS EQUIVALENT 
IN CERTAIN SUPERTYPE CONDITION. 
TYPES ARE ENTERED INTO .CTR FILE 
AS SUPERTYPE <UST OF EQUIVALENT 

TYPES> AFTER THE LEGEND RULE. 
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IF MATCH RULE IS TO APPLY ONLY 
TO PLAIN FILES, THEN SKIP THIS STEP. 

OTHERWISE, .FTR DEVELOPER ADDS 
SPEGALFILE UNE TO .CTR FILE AFTER 
SUPERTYPE UNE. (THIS CAUSES RULE 
TO APPLY ONLY TO NON-PLAIN FILES). 



.FIR DEVELOPER CHOOSES BOURNE 
SHELL COMMAND WHICH WILL EXECUTE 

WHEN USER OPENS AN ICON WHICH 
MATCHES THE TYPE. BOURNE SHELL 

COMMAND IS ENTEREDAS CMD OPEN 

<BOURNE-SHELL-COMMAND> AFTER 
THE SPECIALFILE RULE. 



.FTR DEVELOPER CHOOSES BOURNE 
SHELL COMMAND WHICH WILL EXECUTE 
WHEN USER ALTOPENS AN ICON WHICH 
MATCHES THE TYPE. BOURNE SHELL 
COMMAND IS ENTERED AS CMP ALTOPEN 
<BOURNE-SHELL-COMMAND> AFTER THE 
CMD OPEN COMMAND. 



FIG. 3B 
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.FTR DEVELOPER CHOOSES BOURNE 
SHELL COMMAND WHICH WILL EXECUTE 
WHEN USER DROPS ANOTHER ICON 
ONTO AN ICON WHICH MATCHES THE 
TYPE. BOURNE SHELL COMMAND IS 
ENTERED AS CMD DROP <B0URNE- 
SHELL-COMMAND> AFTER THE CMD 
ALTOPEN COMMAND. 



.FTR DEVELOPER CHOOSES 
COORDINATES WHERE ICON WILL BE 
DRAWN. COORDINATES ARE ENTERED 
AS BOUNDS <XMIN>, <YMIN>, <XMAX>, 
<YMAX> AFTER THE CMD DROP RULE. 



.FTR DEVELOPER WRITES DESCRIPTION 

OF ICON IN ICON-DESCRIPTION- 
LANGUAGE. DESCRIPTION IS ENTERED 
AS ICON <JC0N-DESCRIPT10N> AFTER 
THE BOUNDS RULE 



.FTR RLE COMPLETE 



FIG. 3C 



02/20/2004, EAST Version: 1.4.1 



* '-U.S. Patent July 6, 1993 Sheet 6 of 50 5,226,163 



c 



EXECUTIVE: SET FILE 
(CHAR*RLENAME) 



CURRENT RLENAME 
FILENAME 



STORE FULL PATH 
NAME FOR LATER USE 



CURRENT BASENAME 
STR RCHR (CURRENT RLENAME, T); 







CURRENT 
+ 


BASENAME 




DETERMINE BASENAME 



CURRENT FILENAME 
CURRENT BASENAME 



STATTABLE= 
!STAT (CURRENT FILENAME, k STAT BUF) 



DETERMINE WHETHER 
RLE CAN BE STATED 




DETERMINE WHETHER 
FILE IS 
SPECIAL FILE 
OR PLAIN RLE 



ISPEdALFlLE = Ol 



FIG. 4A 
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0 



DO NOT OPEN 
SPECIAUILE; 
MAY HAVE SIDE 
EFFECTS 




SPECIALFILE 2 



FD = OPEN (CURRENT 
FILENAME" O-FD ONLY); 



ONLY ATTEMPT 

TO CACHE 
OPENABLE FILES 




ATTEMPT TO 
OPEN FILE 



DETERMINE 
WHETHER FILE 
IS OPENABLE 



DETERMINE 
WHETHER FILE 
IS CACHEABLE 



CACHEABLE = 
READ (FD, CACHE, CACHESIZE) 



ATTEMPT TO 
CACHE RLE 




| CACHEABLE = 61 | CACHEABLE = 0 | 1 CACHEABLE 



=3 



INDICATE THAT FILE 
HAS NOT BEEN ASCI 
TESTED 



1 ALR EADY ASCI TESTED = 0| 

, 1 , 

C RETURN ) 



FIG. 4B 
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EXECUTIVES SET Fill 



CURRENT BASENAME 
= 0 




OPENABLE 
= 0 



STATTABLE 
= 0 



SPECIAL FILE 
= 0 



CACHEABLE 
* 0 






ALREADY ASCI TESTED 
= 0 







c 



RETURN 



FIG. 5 



02/20/2004, EAST Version: 1.4.1 



_U.S. Patent July 6, 1993 Sheet 9 of so 5,226,163 



( INT EXECUTIVE: RUN (CHAR ♦ PCD, VOID « D SPACE, CHAR * S SPACE) ) 



PC = PCD; 
SET THE WORKING 
PROGRAM COUNTER'S 
VALVE TO THE INITIAL 
PROGRAM COUNTER'S 
VALVE 



STACK P = STACK; 
INITIALIZES THE STACK 
POINTER TO 
POINT TO THE BASE 
OF THE STACK 



NOTE: THE LOOP ENTERED HERE MAY 
ONLY BE EXITED VIA THE OP-END NAME 
CASE BELOW. 



SWITCH (»PC) 




FIG. 6A 
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OPJEQEQi 



pc+4; 

ai=( — stackp)->integer; 
bi=( — stockp)- integer; 
if(oi==bi) 

(stackp++)->integer=1; 

else 

(stockp++)->integer=0; 



0P_C0MPLEMENTi 



pc++; 

ai=( — stackp)- integer; 
if(oi==0) 

(stockp++)->integef=1; 

else 

(stackp++)->integer=0; 



OP.GTi 



pc++; 

bi=( — stackp)- integer; 
ai=( — stackp)- integer; 
if(oi > bi) 

(stackp++)->integer=1; 

else 

(stackp++)->integer=0; 



OP_GEi 



pc++; 

bi=( — stackp)- integer; 
ai=( — stackp)- integer; 
if(ai >=bi) 

(stackp++)->integer=1; 

else 

(stackp++)->integer=0; 



fig. 6B 
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0P_LTi 



pc++; 

bi=( — stackp)->integer; 
ai=( — stackp)->integer; 
if(ai < bi) 

(stockp++)->integer=1; 

else 

(slockp++)->nteger=0; 



0P_LEi 



pc++; 

bi=( — stackp)- integer; 
oi=( — stackp)- integer; 
if(ai <= bi) 

(stackp+ + )- >in teger=1 ; 

else 

(stackp4+)->integer=0; 



OFLNEi 



pc++; 

bi=( — stackp)->integer; 
oi=( — stackp)- integer; 
if(ai != bi) 

(stackp++)->integer=1; 

else 

(stackp* + )->integer=0; 



OfLPLUSi 



pc++; 

bi=( — stackp)- integer; 
ai=*( — stackp)->integer; 
(stackp++)->integer=ai + bi; 



FIG. 6C 20 
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0P_MINUSi 



OPJIMESi 



OP.SLASHi 



OP.MODi 



0P_ANDi 



pc++; 

bi=( — stockp)->integer; 
ai=( — stackp)- integer; 
(stackp++)->tnteger=ai - bi; 



bi=( — stockp)->integer; 
ai= ( — stackp)- integer; 
(stackp + + )- >in teger= ai * bi; 



pc++; 

bi=( — stackp)- integer, 
oi=( — stackp)- integer; 
(stackp++)->integer=ai / bi; 



pcf+; 

bi=( — stackp)->integer; 
ai=( — stackp)->integer; 
(stackp++)->integer=oi % bi; 



Ec++; 
i=( — stackp)- >integen 
ci=( — stackp)->integer t 
(stockp+ + )- integer- oi k bi; 

FIG. 6D 
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OP.ORi 



pc++; 

bi=( — stackp)- integer; 
oi=( — stockp)- integer; 
(stackp++)->integer=ai I bi; 



0PJ(0Ri 



pc++; 

bi=( — stackp)- integer; 
oi=( — stackp)- integer, 
(stockp++)->integer=oi A br, 



OP_ANDANDi 



pc++; 

bi=( — stackp)-»nteger, 
oi=( — stackp )->integer, 
if(oi != 0 kk bi != 0) 

(stackp+ + )->in teger=1 ; 

else 

(stackp+ + )->in teger=0; 



OP.ORORi 



pc++; 

bi=( — stackp)- integer; 
oi=( — stackp)- integer; 

if(ai != 0 II bi != 0) 

(stackp++)->integer=1; 

else 

(slackp4+)->integer=0; 



0P_POPi 



pc++; 
— stackp; 



t 

5 



FIG. 6E 
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OPJBEOi 



if((stockp-1)->integer==0) { 
pc++; 

GETOPERAND; 

pc = pcO + operond.integer; 

| else { 

pc += 5; 



v. 



0P_BND 



if((stockp-1 )->integeri =0) | 
pc++; 

GETOPERAND; 
. pc = pcO + operond.integer; 

} else { 

pc += 5; 

I 



OPJBR 



pc++; 

GETOPERAND; 

pc = pcO + operond.integer; 



0P_UBEL 



pc++; 



OP.STOREi 



pc++; 

GETOPERAND; 

ai = (stackp-1)- integer, 

»(int»)((chor»)dspace + operond.integer)=ai; 



FIG. 6F 
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OP_LOA0i 



0P_L0ADCi 



0P_ASCH 



I 

7 



pc++; 

CETOPERAND; 

ai=*(int*)((char*)dspoce + operand.integer); 
(stockp++)->integer = ai; 



pc++; 

GETOPERAND; 
oi=operond. integer; 

(stackp++)->integer = ol; 



pc++; 

if(AlreodyAsciiTested) [ 

( stackp+ + )- >inleg er= AsciiTestR esult; 
break; 

I 

if('Cacheable) { 
ai=0; 

else if(Cachesize<1) j 

I else { ° i=0i 
ai=1; 
p=Cache; 
p2=p+CacheSize; 
while(p!=p2) { 

if(!isoscii(*p|j { 
breok; 

j p++; 

I 

AI read y AscfiTested= 1 ; 
AsciiTestResult=ai; 

(stockp+ +)->m teger= AsciiTestR esult; 



FIG. 6G 
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0 



0P.M0DE 



pc++; 

if(Stottable) 

(stockp++ )->integer=stotbuf.st_ mode; 

else 

(siockp+4 )- >integer=- 1 ; 



OP.SIZE 



pc+f; 

if(Stattable) 

(stockp++)->integer=statbuf.st_size; 

else 

(stockp+-f)->integer=-1; 



OPJJNKCOUNT 



pc++; 

if(Stattoble) 

(stackp++)->integer=stotbuf.st_ size; 

else 

(stackp++)->integer=-1; 



OP.TAG 



//See attached detail on sheet XXX 



FIG. 6H 
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0P_CHAR 



9 



pc++; 

ai=( — stackp)->toteger; 
H(oi<D) 

bi=-1; 
else lf(!Openoble) { 
W-- 1; 

else lf(Cocheable) | 

if(ai+sizeof(char)<=CocheSize) { 

bl=(char)Coche[aiJ 
} else if(CacheSize1=CACHESEE) { 
bi=-1; 



else { 



else [ 



statu s=getnum(fd,oi,Achartmp,1); 
H(stotus !=0) 
bi=-1; 

else 

bl=chartmp; 



status=getnum(fd,oi,iechortmp,1); 
if(stotus !=0) 
bi=-1; 

else 

bi=chort/np; 



|stackp++)->integer=bfc 



FIG. 61 
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0P.SH0RT 



10 



pc++; 

oN(— stockp)->lntegen 
lf(oi<0) 

bM-1; 
else W(!0penable) { 
bi=-1; 

else ff(Cachcoble) { 

lf(al+sfeeofi(short)<=CacheSize) { 

shorttmp=getshort((char»)ACoche[al]); 
bi=shorttmp; 
| else if(CocheSrze !=CACHE3Z£) { 
bi=-1; 



I 

dse { 



else { 



status=getnum(fd,oi,tehorttmp l 2); 
if(stattus !=0) 
bi=-1; 

else 

bhshorttmp; 



siatus=getnum(fd t ai&shorttmp l 2); 
lf(stotus 1=0) 
bi=-1; 

dse 

bi=shorttmp 



(stockp++)->inte9er=bi; 



FIG. 6J 
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OPJLONG 



11 



pc++; 

ot=( — stockp)->mtegen 

lf(ai < 0) 

bl * -1; 

else if(!Openoble) ] 

j bi = -1; 

else if(Cocheable) { 

if(oi+sizeof(lofig) <= CacheSbe) f 

longtmp=getlong((chcr*)4Coche[ai]); 

bi = longtmp; 
| else lf(CocheSize 1= CACHESZE) i 

i bl = " ,: 

else { 

status=g€tnum(fd,ol,aongtmp,4); 
ff(stotijs != 0) 

bi = -1; 

else 

^ bi = longtmp; 



I 



1 



$tatu$=getnum(fd l al l tfongtmp,4); 
tf(status != 0 

bl = -1; 

else 

bi » longtmp; 



($tockp++)->integer = bi; 



FIG. 6K 
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<8> 



OPJJCHAR 



t 

12 



pc++; 

ol=( — stockp)->integer; 

tf(oi < 0) 

bi = -1; 
if(!0penable) f 

i bl = - ,: 

else if(Cacheable) { 

lfl;ai+si2eof(urisigned char) <= CacheSize) { 

b! = (unsigned chor)Cache[al) 

} else (((CacheSize != CACHESIZE) { 

bi = -1; 

else { 

status=9etnum(fd,ai,&uchartmp,1 ); 

if(status != 0) 
bi = -1; 

else 

bi = uchortmp; 



else { 



status=getnum(fd,a!,feichartmp,1); 

!f(status != 0) 
bi = -1; 

else 

bi = uchartmp; 



! 

(stockp++)->mteger = bi; 



FIG. 6L 
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0PJJSH0RT 



pc++; 

oi=( — stockp)->tnteger; 

if(oi < 0) 

bi = -1; 
else if(!0penable) } 

bi = -1; 

else if(Cacheable) { 

lf(ol+sizeof(unslgned short) <= CocheSIze) { 

ushorttmp=aetshort((chof*)leCoche[ai]); 
bi = ushorttmp; 
jelse lf(CocheSize != CACHESZE) { 
bi = -1; 



else j 



I 



stotus=gctnum(fd ) ai,ftushorttmp # 2); 

lf($tatus != 0) 

bi = -1; 

else 

bi - ushorttmp; 



status=getnum(fd ( ol l fcjshorttmp f 2); 

lf(stotus != 0) 
bi = -1; 

else 

bl = ushorttmp; 



} 

(stockp++)->integer = bi; 



13 



FIG. 6M 
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OP.ULONG 



pc++; 

oi=( — stockp)->integen 

iffoi < 0) 

bi = -1; 
else if(!Openoble) { 

bi = -1; 

J 

else if(Cocheable) { 
iffoi+siz 



else { 



ff(oi+sizeof(un$igned long) <= CacheSize) { 
ulongtmp=getlong((ch<jr»)*Cache[ai]); 
bi = ulongtmp; 
j else if(CocheSize != CACHESIZE) { 

else { 

stotus=Qetnum(fd,al,ifljlongtmp,4); 
ff(stotus != 0) 
bi = -1; 

else 

bi - ulongtmp; 



stotus=g€tnum(fd,ol,4ajlongtmp,4); 
iffetotus != 0) 

else W " " 1: 

bi = ulongtmp; 



i 

(stock++)->integer = bi; 



14 



FIG. 6N 
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0P_PUSHS1RING 



pc++; 

GETOPERAND; 

bi = strien(s$poce+opwarid.integer)+1; 
ai = (int) new charfbi) 
bcopj(sspoce+operon<tlnte9er,((*ar»)<ii,bi); 
(stackp++)->Weger = ai; 



OPJNDNAME 



pc++; 

oi=( — stackp)->mteger, 
if(oi != 0) { 

retum(1); 

| else | 

retum(O); 



(OP_ENDNAME olwoys returns) 



0PJ5TRCMP 



pc++; 

bi=( — stockp)->integer; 
ai=( — stackp)->ntegen 

(stockp++)->ff»teger = !stranp((chor»)ol,(chor»)bl); 
delete (chart)ai; 
delete (chor»)bl; 



15 



FIG. 60 
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® 



OPJJIRCONTAINS 



pc++; 

oi=( — stockp)->irrteger; 
bl=strien(CurrentRleName); 
i*strien((char*)ai); 
H(i+M+1 >= 256) { 

delete (chor»)ai; 

(stockp++)->inkeger=0; 

} else { 

bcop/GjrrentfileName.Sw^ 
Seorchfienamefbi)= t / , ; 
bcopy((chor«)aLSeorchfienome+bi+1 
Seorchfienome[bi+i+1]=0; 
stotus=siot(S€irchfBenQme,4dircontoin$buf); 

delete (chor»)ar, 

jf(status==0) { 

(stockp++)->Meger=1; 

} else [ 

(stockp++)->integer^O; 

i 



t 

16 



FIG. 6P 
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® 



0P.STRING 



t 

17 



pc++; 

bl=( — stockp)->integen 

al=( — stockp)->fntegen 

if(!0penable II oi < 0 II bl< 0) { 

p = new char[1) 
«p = 0 

(stockp+ +)- >intc5er * (jnt)p; 

else if(Cocheable) { 

if(ai+bi <= CocheSize) { 

p = new chor[bl+1J 
for(i=0;W)l;l++)p[i)=Coche[<jH]; 

(stackp++)->integer = (W)p; 

} else if(CacheSize != CACHESZE) { 

p = new chor[l]; 
*P = 0; 

(stackp++)->mteger = (ht)p; 



} else 



else { 



lseek(fd,al,0); 
p = new chaffbi+1 J 
read(fd.p,bi); 
p[bi] = 0; 

(stackp++)->integer = (int)p; 



lseck(fd,oi.O); p , 
p = new char[bl+1) 
read(fd,p,bi); 

rfbi] = 0t 

(stackp++)->integer = (int)p; 



fig. 60 



20 



02/20/2004, EAST Version: 1.4.1 



U.S. Patent 



July 6, 1993 



Sheet 26 of 50 



5,226,163 



® 



op.glob 



pc++; 

bi=( — stockp)->mtegen 
a'i=ao6Uat<±(Curr-entBaseNome,(char»)bI); 
($tackp++)->toteger = ai; 
delete(char*)bi; 



OP_PRINTi 



pc++; 

al=( — stockp)- integer; 
prlntfC'WO.oi); 



OP_PRiNTs 



a!=( — stockp)->integer, 

printf("XsO,ai); 

delete(char*)at 



IB 



FIG. 6R 
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T defoult 

// Handle invalid opcode error condition. 
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© 



PC++ 




(Stockp++) 

♦ INTEGER 
= -1 



UNCACHEABLE FILES HAVE 
-1 PUSHED ON THE 
STACK BY OP_TAG TO 
INDICATE NOT TAGGED. 



IF ItS TOO SMALL TO BE A MIPS 
EXECUTABLE, THEN SKIP AROUND 
THE TEST FOR MIPS EXECUTIVE. 



AT THIS POINT, THE FIRST Z BYTES OF THE 
FILE ARE 0x0160, SO WE KNOW IT'S NOT A 
SCRIPT. SO IF IT FAILS THE SUBSEQUENT 
TESTS ITS NOT A TAGGED FILE. 



(Stockp++) 

♦ INTEGER 
= -1 

— 



PUSH -1 IF NOT 
A MIPS 
EXECUTABLE. 



(Stackp++) 

♦INTEGER 
= -1 

— e: 



) PUSH -1 IF NOT 
) TAGGED. 



(Stockp++) 

♦ INTEGER 
« -1 



I PUSH -1 IF NOT 
) EXECUTABLE. 



f 
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1 



(Stackp++) -^INTEGER 
= getlong(&Coche[68Tj 



PUSH THE TAG VALVE 
ONTO THE STACK 



AT THIS PONIT. WE KNOW THAT THE RLE 
Ik) IS NOT A MIPS EXECUTABLE. IT STILL MAY 
-•-BE A TAGGED SHELL SCRIPT THOUGH. 



(Stockp++) 

— INTEGER 
= -1 

<d 



(Stackp++) 

♦ INTEGER 
= -1 




A TAGGED SHELL 
x SCRIPT MUST BE AT 
{LEAST 12 BYTES LONG. 
) UNE 1:#/x\n =5chars 

#TAG 1\n =7chars 



x A TAGGED SHELL 
I SCRIPT MUST BEGIN 
) WITH THE 2 
CHARACTERS 'f' 



IF THE FIRST UNE 
) DOES NOT END IN A 
f NEWUNE BEFORE THE 
' END OF THE CACHE. 
PUSH -1. 



IF THERE IS NOT 
) ENOUGH SPACE l£FT 
\ IN THE CACHE TO 
' HOLD THE SECOND 

UNE, PUSH -1. 



FIG. 7B 
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1 



) MAKE i 8E THE INDEX OF THE 
\ FIRST BYTE OF THE SECOND LINE 




)lF THE SECOND LINE DOES'NT 
} START KWTH'#Togsp', THEN -1. 



5 5 1 1 MAKE i BE THE INDEX 
1 J OF THE TAG NUMBER. 



oi = strotal( 
*Coche[iJ,6p, 
0) 



SET fli TO THE TAG NUMBER. 




(Stackp++) 

♦ INTEGER 
= -1 

d 



IF THE TAG NUMBER IS 
MALFORMED. THEN PUSH 
-1 



(Stackp++) 

♦ INTEGER 
* -1 



) IF THE RLE IS NOT 
| EXECUTABLE, PUSH -1 



PUSH THE TAG VALVE ONTO THE STACK 



FIG. 7C 
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(50.75) 




(100,100) 



(-20,-20) 



ICON COORDINATES 



Y 

FIG. 8A 



? AXIS 

Y AXIS. AXIS 
1 



TRUE 
VERTICAL 



TRUE HORIZONTAL 



FIG. 8B 
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(EXECUTIVE: SET STATE( INT OPENED, INT DISABLED, "\ 
INT LOCATED, INT SELECTED, INT CURRENT) J 



ICON OPENED STATE 


= OPENED 






ICON DISABLED STATE 


= DISABLED 



ICON LOCATED STATE = LOCATE) 



ICON SELECTED S 


TATE = SELECTED 






ICON CURRENT STATE = CURRENT 







Q RETURN ^ 



FIG. 9A 
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c 



EXECUTIVE: SETCOLORS (INT SHADOW, 
INT ICON, INT OUTLINE) 



D 



ICON SHADOW COLOR = SHADOW 






ICON ICON COLOR = ICON 






ICON OUTLINE COLOR = OUTLINE 







Q RETURN 



FIG. 9B 
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INT EXECUTIVE: RUN (CHAR*PC0, 
VOIDOSPACE, CHAR*SSPACE) 



PC = 


PCO 






STACKP 


= STACK 






CURCOLOR = 0 




SET THE PROGRAM 
COUNTER TO ITS 
INITIAL VALUE. 



INITIALIZES THE STACK 
POINTER TO THE BASE 
OF THE STACK 



SET THE INITIAL COLOR 



} INITIALIZE THE NUMBER 
OF VERTICES IN THE 
CURRENT POLYGON. 



NOTE: 



THE LOOP ENTERED HERE 
MAY ONLY BE EXITED 
THROUGH OPJNDPROG 

case Baow. 
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OP_EQE0f 



pc++; 

of=( — stockp)->flt 
bf=( — stackp)->flt: 
if(af == bO { 

(stockp++)->flt = 1.0. 

| else { 

(stackp++)->flt = 0.0; 

I 



0P_C0MPL£MENTf 



0P_GTf 



OP.GEf 



102 



pc++; 

of=(~3tockp)->flt; 
ifCof == 0.0) 

(stackp++)->flt = 1.0; 

else 

(stockp++)->flt * 0.0; 



pc++; 

bf=( — stockp)->flt; 
af=( — stockp)->flt; 
lf(af > bf) 

(stockp++)->flt = 1.0; 

else 

(stockp++)->flt = 0.0; 



pc++; 

bf=( — stockp)->flt; 
of=(— stockp)->flt; 
if(of >= bf) 

(stockp++)->flt = 1.0; 

else 

(stackp++)->flt = 0.0; 



FIG. 10B 
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® 

i 



OPJJf 



pc++; 

bf=( — siockp)->flt; 
of=(— stockp)->flt; 
if(of < bf) 



else 



(stockp++)->flt = 1.0, 
(stockp++)->flt = 0.0; 



OPJIf 



pc++; 

bf=(— stockp)-Xit; 
of=(— stockp)->flt; 
lf(of <= bf) 



else 



(stackp++)->flt = 1.0; 
(stackp++)->flt = 0.0; 



OP JO 



pc++; 

bf=(~stockp)->flt; 
af=( — stockp)->flt; 
H(of != bO 



else 



(stackp++)->flt = 1.0; 
(stockp++)->flt » 0.0; 



0P_PLUSf 



pc++; 

bf=(— 3tockp)->flt; 
of=(~stockp)->flt; 

(stackp++)->flt = of + bf; 
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FIG. 10C 
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OPJIINUSf 



pc++; 

bf=(— stockp)->flt; 
af=( — stockp)->flt; 
(stockp++)->flt = of - bf, 



OPJIMESf 



pc++; 

bf=( — stockp)->flt; 
af=(— stackp)->flt; 

(stackp++)->flt = of * bf; 



OP_SLASHf 



pc++; 

bf=(— stockp)->flt; 
of=( — stockp)->fil; 
(stackp++)->flt = of / bf; 



OPJIOOf 



pc++; 

bf=(— 8tackp)->flt; 
af=(— stockp)->flt; 

(stockp+-f )->fl( = bttpat(af) % bitpat(bf); 
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FIG. 10D 
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OPJWDf 



OP.ORf 



OPJCORf 



0P_XOVE 



f 

105 



pc++; 

bf=(— stockp)->flt; 
of=(— Btockp)->flt; 

(stockp++)->flt = bitpat(af) & bftpot(bf); 



pc++; 

bf=(— stockp)->flt; 
<rf=( — stockp)->flt; 

(stackp++)->flt = bitpat(af) I bitpat(bf); 



pc++; 

bf=( — stockp)->flf 
af=(— stockp)->m; 

(stackp++)->flt = bitpot(aO A bitpot(bf); 



pc++; 

cy=(stackp-1)->flt; 

cx=(stockp-2)->flt; 

stockp -= 2; 
nverts=0; 



fig. ioe 



116 



02/20/2004, EAST Version: 1.4.1 



U.S. Patent July 6, 1993 Sheet 39 of 50 5,226,163 



® 



OPJJRAW 



pc4+; 

of=(stockp-2)->fit; 

bf=(stockp-1)->flt; 

stockp -= 2; 
nverts=0, 

withStdColor(curcolor) [ 

move2((Coord)cx,(Coord)cy); 
draw2((Coord)af,(Coord)bf); 

cx=of, 
cy=bf; 



op.caoR 



pc++; 

curcolor = (int)((~stackp)->flt); 



OPJGN 



pc++; 
nverts=0; 



OP_PMV 



pc++; 

pos[0].y = (stockp-1)->flt; 

posfOjx s (stockp-2)->flt; 

stockp -= 2; 
nverts=1; 
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FIG. 10F 
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OP.VERTEX 



pc++; 
inverts < 255) j 



pos[nverts].x=(stackp-2)->flt; 

pos(nverts].y B (stockp-1 )->flt; 

nverts++; 
stackp -= 2; 



0P_P0R 



pc++; 

inverts < 255) { 



pos[nverts].x=(stackp-2)->flt; 

pos[nverts].y=(stackp-1 )->flt; 

nverts++; 
stackp -= 2; 



0PJ>CL0S: 



pc++; 

withStdColor(curcolor) { 

if(nverts)pmv2((Coord)pos[0].x,(Coord)pos[0).y); 

for(i=1;f<hverts:i++) ( 

I pdr2((Coord)pos[i].x,(Coord)pos[i}y); 

pdosQ 
nverts=0, 



OP_ENDaOSEDUNE 



pc++; 

wHhStdColpr{curcolor) { 
bgndosedlineOf 

forfhO; inverts; i++)v2f(«pos[i] > x); 
enddosedlineO; 

nverts=0; 
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FIG. 10G 
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0P_ENDUNE 



pc++; 

wlthStdColor(curcolor) j 
bgnlineft 

for(i=0; (Averts; i++)v2f(4pos[i}x); 
enalineOc 

nverts=0; 



0P_ENDP0INT 



pc++; 

withStdColor(curcoior) { 
bgnpointQ 

for(i=0; i<h verts; i++)v2f(4pos[i].x); 
endpointOt 

nverts=0; 



0P_£NDP0LYG0N 



pc++; 

withStdColor(curcolor) { 
bgnpolygonft 

for(i=0; i<n verts; i++)v2f(*pos[i]j(); 
endpolygonQi 

nverts=0; 



108 



FIG. 10H 
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0P_END0U1UNEP0LYGON 



0PJCL0S 



109 



pc++; 

oi=(intX(~stockp)->flt); 
withStdColor(curcoior) { 

bgnpolygonO: 

for(i=0;i<nverts; i++)v2f(4pos[i].x); 
I endpolygooQ 

withStdCcJor(oi) { 

bgn closed! in eQ 

for(i=D; inverts; i++)v2f(4pos{i}x); 
endclosed'meO 

nverts=0; 



pc++; 

oi=(int)(( — stockp)->flt); 
withStdColor(curcolor) { 

if(nverts)pmv2((Coord)po8[0].)c(Coord)pos[0}y); 

for(i=1;i<n verts; 

pdr2((Coord}pos[i)x,(Coord)po3[i}y); 

pdosQ 

withStdColor(Qi) { 
if(nverts) 

move2((Coord)pos[0].x,(Coord)pos[0}y); 
forf>1;i<n verts; 

draw2((Coord)pos[l3.x.(Coord)pos[i}y); 
^ drow2((Coord)pos[0].x,(Coord)pos[0].y); 

nverts=0; 



FIG. 101 
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OPJWC 



pc++; 

ef=(— stackp)->flt; 
df=( — stackp)->flt: 
cf=( — stackp)— >flt 
bf=( — stockp)->flt; 
of=(~stockp)->flt; 
withStdColor(curcotor) ( 

ore ((CwdKlCoordJbf^CoordJcf.fAngleJdf, 
(Angle)ef); 



0P_ARCF 



pc++; 

ef=(— stockp)->flt; 
df=( — stockp)->flt; 
cf=( — stockp)->flt; 
M»(~ stockpj-Xlt; 
of=( — stackp)->flt; 
withStdColor(curcolof) j 

<jrcf((Coord)of,(Coord)bf,(Coord)cf,(Angle)df 1 
(Angle)cf); 



f 
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FIG. 10J 
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OPJENDPROG 



pc++; 
retum(l); 



OP_ANDANDf 



pc++; 

bf=(— stockp)->flt; 
af=(--stockp)->flt; 
if(of != 0.0 ttkbl != 0.0) 

(stockp++)->flt = 1.0; 

6lS6 

(stackp++)->flt = 0.0; 



—n N 

( 0P_ENDPR0G ^ 
y always returns J 



OP.ORORf 



pc++; 

bf=( — stackp)->flt; 
af=(~stockp)->flt; 
if(of != 0.0 II bf != 0.0) 

(stockp4+)->flt = 1.0; 

6lS6 

(stockp++)->flt = 0.O, 



0PJ»0Pf 



pc++; 
— stockp; 
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FIG. 10K 
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OPJEQf 



OPJJNEf 



OP JR. 



if((stackp-1)->M == 0.0} { 
pc++; 

GETOPERAND; 

pc = pcO + operandinteger, 

! else j 

' pc += 5; 

I 



if((stockp-1)->fit != 0.0) { 
pc++; 

GETOPERAND; 

pc = pcO + operandinteger, 
' pc += 5; 

I 



pc++; 

GETOPERAND; 

pc = pcO + operandinteger. 



v. 



0P_LABEL 



pc++; 



OP_STOREf 



pc++; 

GETOPERAND; 
af=(stackp-1)->fit; 

»{floot*)((ctior*)dspace + operondmteger)=af; 
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FIG. 10L 
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0P_L0ADf 



pc++; 

GETOPERAND; 

of = *(floot*)((char»)dspoce + operand'mteger); 
(stockp++)->flt = of; 



0PJ.0ADCf 



((char«)stockp)[0]=pc[1j 

((char»)stockp)[1 >pc[2j 

((chor«)stockp)[2}=pc[3j 

((char»)stockp)[3>pc[4j 

stackp+4; 
pc += 5; 



OPJHJSHSTRING 



pc++; 

GETOPERAND; 

bi = sWen(sspoce4operondinteger)+1; 
ai = (kit) new charfbl} 
bcopy(sspoce+operQn4integer,(chor«)oi,bi); 
(stackp++)->integer = oi; 



0P_STATE0PENED 



pc++; 

(stackp++)->flt = IconOpenedStote; 



? 
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FIG. 10M 
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t 



0P_STA1E0ISABI£D 



pc++; 

(stockp++)->flt = IconDisabledStote; 



0P_STAHLOCATED 



pc++; 

(stackp++)->flt = IconLocotedStote; 



OP_STATESELECTE0 



pc++; 

(stockp++)->flt = IconSelectedStote; 



0P_STA7ECURRENT 



pc-H-; 

(stockp++)->flt = IconCurrentStote; 
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FIG. ION 
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OP.SHA0OWCOLOR 



pc++; 

(stackp++)->flt = IconShodowcolon 



0PJCONCOL0R 



pc++; 

(stockp++)->flt = Iconlconcolon 



OP.OUIUNECOLOR 



pc++; 

(stockp++)->flt = IconOutlinecolor, 



OPJWNTf 



pc++; 

af=(— stockp)->flt; 
prlntfC»0.af); 
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FIG. 100 
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0P_PRINTs 



pc++; 

oi=( — stackp)->integen 
printf("Xs0.al); 
delete (chor*)oi; 



default 



// Handle illegal opcode condition 



fig. iop 
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FILE CHARACTERIZATION FOR COMPUTER 
OPERATING AND FILE MANAGEMENT 
SYSTEMS 

5 

BACKGROUND OF THE INVENTION 

The present invention relates to computer operating 
and file management systems, particularly to improve- 
ments in tools for such systems which enhance user 
productivity, system management and availability of 10 
such systems to a broader spectrum of user levels of 
expertise. In the context of this invention a too), is a 
compact computer program or routine designed to do a 
specific task well. Typically, several tools can be linked 
together to perform more complex tasks. 15 

The present invention may be used with graphical 
user interfaces for use in computer systems of all types 
and sizes, including large scale mainframes, worksta- 
tions and microcomputers, whether or not any of the 
computers are coupled together in a network. In panic- *0 
ular, the present invention provides consistent charac- 
terization of system files, and the definition and design 
of the functionality and appearance of icons and sym- 
bols used with operating environment programs. 

As more computing power is introduced into micro- 25 
processor technology and the cost- and size-per-bit of 
memory devices decreases, more sophisticated pro- 
grams can be operated on smaller and more compact 
computer systems. Thus, stand alone microcomputer 
systems presently available are beginning to approach 30 
the speed and computing power, i.e. instruction 
through-put, of workstations, which, in turn, are begin- 
ning to rival main frame computers in their capacity for 
processing complex computing operations. 

Most computer systems designed for use by sophisti- 35 
cated users require a high level of expertise and long 
hours of familiarization and setup. Typically, thorough 
knowledge of complex sets of non-intuitive input/out- 
put commands and procedures is required before such 
users can become productive. If the operating and file 40 
management systems are changed very substantially as 
such systems are improved and enhanced, such users 
must relearn new commands and techniques before 
becoming fully productive again. Even experts are hin- 
dered by complex mechanics of interfacing with such a 45 
system. 

Nowadays workstations are often part of, or planned 
for use in, a network. Networks typically require sys- 
tem administration which in the past has been left to the 
most expert-level user in view of the complexities asso- 50 
ciated with management of system resources and users. 
However, the increasing number of workstation users 
whose expertise does not include system administration 
highlights the need to simplify network system adminis- 
tration. In particular, system administration tasks that 55 
involve customizing a workstation to a user's needs and 
preferences can and should be done by the users them- 
selves rather than the system administrator. 

Many sophisticated workstation networking systems 
provide disjoint mechanisms for customizing each work 60 
station. These mechanisms usually include modifying 
some file and following some script or simply issuing a 
set of commands The scripts and commands normally 
encrypt a set of non-intuitive options which are focused 
on completing only one portion of the complete task. 65 

Textual scripts are helpful in getting the job done but 
lack feedback. Unless the script has good error and 
detection and correction features, the system manager 
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has no immediate feedback as to whether the process 
really worked. In the graphical user interface of the 
present invention, the manager is presented with a view 
of all of the options and states that disks and file systems 
can achieve without having to know the difficult com- 
mands and procedures to achieve those states. 

User acceptance of a PC-like workstation or worksta- 
tion-like PC is influenced or impacted by the new user's 
initial impression of how easy or difficult it is to bring 
the system into productive use. If the system requires 
the user to learn a set of complex tasks and an array of 
non-intuitive command lines before he can be produc- 
tive, he may feel that he is working for the machine 
rather than that the machine is working for him. Thus, 
presenting a "view". of the system and how it can be 
modified to suit the user's needs and preferences is gen- 
erally regarded as more intuitive and less overwhelming 
than facing a set of complex input/output commands 
and procedures. 

The popularity of graphical user interfaces, which 
employ graphic symbols and analog control of cursor 
movement instead of typewritten entry of commands 
and cursor keys, has grown very quickly and steadily 
with the introduction of personal computers for use at 
home and small businesses by users at all levels of exper- 
tise. A visual interface with a computer system helps 
users feel that their computer is friendlier and, more- 
over, helps the user work more efficiently and produc- 
tively with the system. 

A user-friendly, interactive, intuitive graphical user 
interface to powerful computer systems having exten- 
sive file and database management systems is advanta- 
geous for users at all levels-. If such an interface provides 
an adaptive visual appearance and intuitive flow of 
information including icons for creating, accessing and 
manipulating system files, the entry-level (i.e. beginner) 
user will not be intimidated, the intermediate-level (i.e. 
average) user broadens his expertise faster, the ad- 
vanced-level (i.e. expert) user becomes even more pro- 
ductive, and system administration becomes less com- 
plex and more efficient. 

SUMMARY OF THE INVENTION 

A tool constructed according to the principles of the 
present invention assists the user in managing system 
files and the actions associated with them by a process 
called file typing. If used with a graphical user interface, 
the tool also provides the user with control of the ap- 
pearance and functionality of file icons. 

The present invention is designed for use with power- 
ful, flexible operating systems having the following 
fundamental characteristics: 

1) Substantially, all information is stored in a hierar- 
chy; thus, information may be organized by dividing it 
into various files and directories, which in turn may 
have subfiles and subdirectories. 

2) Each workstation may support more than one user; 
thus, the present invention anticipates a multi-user envi- 
ronment. 

3) The system may support very sophisticated net- 
working software which allows users to access informa- 
tion on other work stations as easily as if the informa- 
tion was installed on that users work station; if used in a 
multi-user, networked system the present invention 
anticipates the need for system administration. 

Using the file typing process of the present invention, 
users can characterize system files, and their associated 
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icons, according to their individual needs and prefer- FIG. 2 is a summary flow diagram for development 
ences. The user may also determine the functionality of of a compiled file of file typing rules according to the 

the icons he derives, principles of the present invention. 

Potentially, an unlimited number of possible file types FIGS. 3A-3C, inclusive, is a summary flow diagram 
can exist in a system for which the file typing process of 5 for deriving file typing rules according to the principles 

the present invention is designed. Such file types in- of the present invention. 

elude plain text files, formatted documents, directories, FIGS. 4A-4B, inclusive, is a flow diagram of the 

shell scripts, images, binary executables and the like. executive program for typing a file according to the file 

Every type of file is given an associated set of opera- typing process of the present invention, 

tions, often unique, that a user would most often want to 10 F]G * 5 a flow diagram of the executive program for 

perform with or on such files. The file type declarations closing a file according to the file typing process of the 

and associated rules provide each type of file with po- present invention. 

tentially unique appearance and behavior customized to FIGS. 6A-6S, inclusive, is a detailed flow diagram of 

the needs and preferences of the user. thc r,le ^P^g process of the present invention. 

As with other systems, icons are used to view file 15 FIGS * 7A-7C, inclusive, is a detailed flow diagram of 

directories, work with existing files and run applica- the opcode "OP TAG" for the file typing process of the 

tions. In addition, icons may be newly created, copied, present invention. 

renamed, removed, printed, transferred or rearranged. F,G 8A derates mapping icons to pixels using the 

Finally, icons may be used for printing the files gener- ^ unds n] * of thc f,lc ,v P m * P™^ 5 of thc P rcscnl 

ated using applications and transferring files to the 20 m Y5 1 n i?°£~ .„ r „ ^ . 

workstations or various storage media such as tape. F,G * 8B 3-D icons using the style 

Thus, the tool of the present invention allows the user conventions of the file typing process of the present 

to use a mouse input device,* cursor icons and pop-up m Xf/il 10 « * n r ^ 

menus to interact with the computer system to access „ . FIG , 9A » 8 " ow d i a * ram »f *e execut.ve program 

sets of files and directories, set personal preferences for M ,he ° f ' COnS ' 8CC0rdm 8 10 lhe P resem 

how the files and directories should be displayed, n « . n r A . 

, , ,. » « » * i * » j FIG. 9B is a flow diagram of the executive program 

launch applications, use basic utility programs and orga- r - , r " t , . 

nize files and directories setting the colors of icons, according to the present 

.... . . . invention. 

it^v P ? i^ V iv mi0 K- M imP UndCr < 30 FIGS. 10A-10P, inclusive, is a detailed flow diagram 

UNIX system. UNIX is highly regarded by experts in of the {cQnK renderi ^ of the t inver f tion . 

computer science as a simple, elegant operating and file FIG. 11 is a face view of an iconic interface for a 

management system for use on computers having differ- compuler file syslem characterized by the file typing 

ent processing power, ranging from microprocessors to proce4s of the m invention , 

mainframes, and providing a common execution envi- 33 - 

ronment across all of them. The system originally de- DESCRIPTION OF THE PREFERRED 

veloped and introduced by Bell Telephone Laborato- EMBODIMENT 

ries in 1969, has become increasingly widespread. Dif- A typica1 mtem for using (hc file typing process of 
ferent versions of it are supported on the equipment of thc present inve ntion includes main computing unit 101, 

several different computer system manufacturers. De- 40 keyboa rd 102, mouse input device 103 with related pad 

tails of the UNIX system are given in the references m and monitor 105 ^ shown in FIG . r Operating 

listed below which are incorporated by reference as if environment programs in a simulated desktop or other 

fully set forth herein. working area metaphor are displayed on the screen of 

Bach. M. J., "The Design of the UNIX Operating display monitor 105. 
System/' Prentice-Hall Software Series, Englewood 45 In most computer systems, the number of files a user 
Cliffs, N.J., 1986. can crea te is limited ultimately by the amount of mem- 
Bourne, S. R., "The UNIX Shell," The Bell System ory available in the system. The file typing process of 
Technical Journal, July-August 1978, Vol. 57, No. 6, the present invention manages numerous varieties of 
Pan 2, pp. 1971-1990. system files and the actions associated with them. Every 
Kemighan, B. W. ( and R. Pike, "The UNIX Pro- 50 type of file, such as plain text files, formatted docu- 
gramming Environment/' Prentice-Hall, Englewood men ts, directories, shell scripts, images and binary en- 
Cliffs, N J. 1984. ecutables, is given an associated set of operations, often 
The version of the UNIX system for which the pre- unique, that a user would most often want to perform 
ferred embodiment of the present invention is imple- on those files. The file type declarations and associated 
memed is called "IRIX", developed and introduced by 55 rules that give each type of file a unique appearance and 
Silicon Graphics, Inc. IRIX is described in "The IRIX behavior are collectively called file typing rules. 
Programmer's Reference Manual/' Vols. I, II, III; "The File typing rules determine how a file of a particular 
IRIX System Adminstrator's Reference Manual"; The type will appear in the operating environment, and also 
IRIX User's Reference Manual/' Vols. I, II; "IRIS-4D define what functions a user can perform on the file by 
Programmers Guide/' Vols. I, II; "IRIS-4D System 60 double-clicking the mouse input device while thc cursor 
Administrator's Guide"; and 'TRIS-4D User's Guide", is located on an associated icon or choosing menu items 
which are also incorporated by reference as if fully set to manipulate the contents of the file. The operating 
forth herein. environment may use the file typing rules to evaluate all 

DESCRIPTION OF THE DRAWING M 1?'^™!^™^^^ 

63 are also used to customize the look of the icons, modify 

FIG. 1 is a system block diagram of a computer sys- what happens to the files the icons represent or to create 

tern for use with a file typing process constructed ac- unique icons when the user is developing an application 

cording to the principles of the present invention. and associated data file. 
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In the present invention, command lines for accessing 
and acting on system files are represented by icons. 
Such command lines arc invoked by the user acting 
upon the icons according to the present invention via 
the mouse device as if they had been typed in a shell. 
Thus the present invention provides the user with 
graphical access for performing sophisticated opera- 
tions on UNIX-based files. 

File typing rules are similar to shell scripts. Shell 
scripts are well known as files containing UNIX instruc- 
tions for creating new UNIX commands. Many of the 
file typing rules are similar also to sets Bourne shell 
commands. C-shells, Bourne shells and shell scripts are 
familiar to those skilled in the use of the UNIX operat- 
ing system. 

File typing rules comprise a type declaration, which 
identifies a unique file type, and a set of as many as 
seven rules following the declaration. All rules, includ- 
ing the type declaration, consist of a rule key followed 
by the rule itself. Rules may be multi-line, but continua- 
tion lines may not begin with any of the rule keys. A 
summary of rule keys, the associated rule and the func- 
tion of the rule is provided in Table I. 

TABLE I 

File Typing Rule Key Function 



TYPE 


declares a new type 


MATCH 


Lets Workspace determine if a file is of 




the declared type. 


LEGEND 


Provides a tern description of the Hie type. 


SUPER TYPE 


Tells Workspace to treai the file as a sub- 




set of « another type under certain cir- 




cumstances 


SPECIAL FILE 


Tells Workspace that the file typing rule 




is to be used only on non-plain files. 


CMD OPEN 


Defines a series of actions that occur 




when the mouse is double-clicked on an 




icon- 


CMD ALTOPEN 


Defines a series of actions that occur 




when the mouse is all -double-clicked 




on an icon. 


CMD DROP 


Defines a series of actions that occur 




when you "drop" an icon on top of 




another. 


CMD PRINT 


Defines a series of actions that occur 




when you choose 'Print* from the 




Workspace or Directory View menus. 


MENUCMD 


Define* menu entries and actions that are 




inserted into the Workspace or Directory 




View menus when an icon is selected. 


BOUNDS 


Defines the coordinate space for the file 




iype*s icon. 


ICON 


Defines (he appearance (geometry) of the 




file type's icon. 



45 



SO 



1.2 The MATCH Rule 



10 



15 



20 



25 



30 



35 



40 



Syntax: MATCH match-expression; 

Description: match-expression is a logical expression 
that should evaluate to true if and only if a file is of 
the type declared by TYPE. The match-expression 
must consist only of valid MATCH functions, as 
described in the section below. The match -expression 
can use multiple lines, but must terminate with semi- 
colon (;). Multiple match-expressions are not permit- 
ted for a given type. The MATCH rule is employed 
each time a file is encountered by the operating envi- 
ronment, to assign a type to that file. 

Example: MATCH glob ("*.h") && ascil; 

L3 Valid Match-Expression 

This section describes the syntax and function of 
valid match-expressions. 

Operators, Constants, and Numerical Representation 

The following C language operators may be used in a 
match-expression: 

+ - * /& I a \% 0 

The following C language conditional operators may be 
used in a match-expression: 

&A 11 !=<> <= > = 

The '==' operator works for string comparisons in 
addition to numerical comparisons. 

The following constants may be used in a match- 
expression: 

true false 

Numbers in match-expressions may be represented in 
either decimal, octal, or hexadecimal notation. These 
representations are given below: 



A description of file typing rules according to the 
present invention is given below with continuing refer- 
ence to FIGS. 2 to 10P. 



File Typing Rules 
1 . 1 The Type Declaration 
Syntax: TYPE type-name 

Description: type-name is a one word ASCII string. 60 
Legal type names can be any legal C language vari- 
able name. The user should ideally choose a name 
that is in some way descriptive of the file type it 
represents. All rules that follow a TYPE declaration 
apply to that type, until the next TYPE declaration is 65 
encountered in the FTR file. Each TYPE declaration 
must have a unique type name. 

Example: TYPE GenericExecutable 



Representation 


Syntax 


decimal 


nuro 


octal 


* On urn 


hexadecimal 


Oxnum 



FUNCTIONS 

Table II describes the set of valid match-expression 
functions. 

TABLE II 



Function Synuj 



Definition 



55 



ascti 
charfn) 

dir contains ("string") 
glob Curing") 

tinkcount 
long (n) 

mode 



Returns TRUE if the first 312 byxes of 
the Ale are all printable ASCII 
characters. 

Returns the nth byte in the file as a 
signed character: range — 128 lo 127 
Returns TRUE if the file b a directory 
and contains the rile named by string. 
Returns TRUE if the file'i name 
matches string; allows use of the follow* 
tng expansions in itring for pattern 
matching: {}{)•? and backslash 
(sec sh(l) filename expansion). 
Returns the number of hard links to the 
file. 

Returns the nth byte in the file as a 
signed long integer; range — 2 31 to 

7" - t. 

Returns the mode bit* of the Ale (see 
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TABLE Il-continued 



Function Synu\ 



Definition 



prim (expr or "itring") 



ihon (n) 



sire 

string (n.m) 



uchar (n) 



ug 



oshort (n) 



chfflod(D). 

Prims the value of the expression expr 
or siring to stdoul each time the nilc is 
evaluated: used Tor debugging. Always 
returns true. 

Returns the nth byte of the file as a 
signed short integer; range —32768 
to 32767. 

Returns the size of the file in bytes. 
Returns a string from the file that is 
m bytes (characters) long, beginning at 
the nth byte of the fik. 
Returns the nth byte of the file as 
an unsigned character; range 0 to 255. 
Returns the specific Workspace 
application ug injected into an 
executable file by the tag injection 
tool (see ug(1) in Appendix D, 
"Workspace Man Pages"). 
Returns the nth byte of the file as an 
unsigned short integer; range 0 to 65535. 
Returns - I if the file is not a tagged 
file. 



10 



15 



20 



25 



1.4 Building Effective MATCH Rules 

A match rule consists of a sequence of expressions, 
each of which checks a file for positive distinguishing 
characteristics. The most effective way to order these 
expressions in a single MATCH rule is to choose a set of 
expressions, each of which tests for a single characteris- jo 
tic, and conjoin them alt using 'and' conditionals (&&). 

The order in which the expressions in a MATCH rule 
are conjoined may have an effect on the efficiency of 
the rule's evaluation. The user should always try to 
order the expressions so that the maximum number of 35 



do not end in 4 \c" than there are files that are not ASCII 
text. 

The user should also make sure that the match rule is 
specific enough not to M catch M any unwanted flies. FTR 
files are scanned sequentially (see Section 2.10, "Com- 
paring FTR Rules"), so if a type is defined with the 
following MATCH rule at the beginning of the FTR 
file, 

TYPE foo 

MATCH ascil; 
every text file in the system will be defined as a file of 
type *foo\ 

1.5 Tagging Executables 

The most preferable way to match a specific execut- 
able to a file typing rule is to "tag" it with a unique 
32-bit number, tag (1) allows the user to inject a 32-bit 
tag safely into a shell script of MIPS executable, where 
it can be read by a MATCH rule using the tag match- 
expression function (see Section 1.3). 

1.6 Programming the IRIS Operating Environment 

An operating environment in accordance with the 
present invention is the IRIS Operating Environment, 
developed and introduced by Silicon Graphics, Inc. 
IRIS, including its icon-based interface called Work- 
Space, is described in "Programming the IRIS Work- 
Space"; "The Personal IRIS Owner's Guide"; and 
"The IRIS-4D Series Owner Guide", which are also 
incorporated by reference as if fully set forth herein. 

The upper 1 6 bits of the tag number are reserved for 
vendor ID, for separate administration by the vendor. 
The lower 16 bits are for general use. Several uses val- 
ues for the lower 16 bits have been defined, which Op- 
erating Environment recognizes: 



/• The different classe* of how to launch an executable */ 



0 define GENERICEXEX 


0x00000000 


/* this can be windowed or no output */ 




# define LAUNCHEXEC 


0x03000100 


/• fire* a launch window for arg input V 




0 define OUTEXEC 


0x00000200 


/• output only wsh •/ 




0 define TTYEXEC 


0x00000400 


/* wsh that ukc* input and ouput V 




0 define TTY LAUNCHEXEC 


TTYEXECI LAUNCH EXEC 


0 define TTYOUTEXEC 


TTYEXECIOUTEXEC 


0 DEFINE TTYLA UN CH OUTEXEC 


TTYEXECIOUTEXECILAUNCHEXEC 


/* Define to represent the number of args 




an executable expects V 




0 define ARGSO 


0x00000000 


0 define ARGS1 


0x0000000 t 


0 define ARFS2 


0x00000002 


0 define ARGS3 


0x00000004 


0 define ARGSO-I 


OiOOOOOOOS 


0 define ARGSO-N 


0x00000010 


0 define ARGS1-N 


0x00000020 



files are 'weeded out* by the first expressions. The rea- 
son for this is that, as in the C language, && will stop 
evaluation as soon as one side of the conditional is found 60 
to be false. Therefore, as a rule of thumb, the more 
likely an expression is to be false, the further to the left 
of the MATCH rule you should place it. 

For example, one possible way to match a C source 
file is with the following rule: 65 
MATCH glob r».c") && ascii; 
Note that it is more efficient to place the glob ("*.c") 
expression first because there are many more files that 



1.7 The Legend Rule 
Syntax: LEGEND text-string 

Description: text-string is a string that describes the file 
type in plain language a user can understand. The 
legend is used to describe the file in the Get File Info 
window. It is also used when a Directory View win- 
dow is set to display as a list. Legends that are longer 
that 25 characters may be truncated in some circum- 
stances. 

Example: LEGEND C program source file 1.8 The 
Supertype Rule 
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Syntax: SUPERTYPE type-name [type-name . . . ] 
Description: The SUPERTYPE rule is used to indicate 
thai a particular file type can be treated as a part of a 
more general file type for under certain conditions. A 
special case in the operating environment is directo- 5 
rics; the user may wish to create a directory with a 
custom icon, yet still have the OPEN and ALTO- 
PEN rules work as a normal directory. (Note: the 
operating environment automatically handles the 
OPEN and ALTOPEN rules for directories; the W 
OPEN and ALTOPEN rules arc placeholders.) A 
unique directory TYPE, with its own ICON rule may 
be created, but if SUPERTYPE is used, it will work 
like a standard directory (see example.) SUPER- 
TYPE is also very useful for printing, where a cus- 15 
torn file type may want to be printed as, say, an 
ASCII file. The user can also make use of SUPER- 
TYPEs in separate OPEN, ALTOPEN, DROP, and 
PRINT rules by using is Super (1) as part of those 
rules. A given file typing rule may contain several 
different SUPERTYPE rules, and thus be considered 
a subset of several more general file types. 



10 

1.11 The CMD ALTOPEN Rule 



Example: TYPE My Directory 

SUPERTYPE Direciory 



20 



25 



30 



40 



1.8 The Special File Rule 

Syntax: SPECIALFILE 

Description: SPECIALFILE is used to distinguish a 
file typing rule used for matching non-plain files. 
Device files, and other non-plain files can cause dam- 
age to physical devices if they are matched using 
standard file typing rules. Special files are only 
matched using rules containing SPECIALFILE, 
which are written so as not to interfere with actual 
physical devices. Similarly, plain files are not 
matched using rules containing a SPECIALFILE 
rule. 

Example. SPECIALFILE 

1.2 The Command (CMD) Rules 

The CMD rules determine how an icon behaves 45 
when a user interacts with it, whether it is by clicking, 
dragging, or through menu selections. 

1.10 The CMD Open Rule 

Syntax: CMD OPEN sh-expressions(; sh-expression; . . $q 
. ; sh-expression) 

Description: The OPEN rule is invoked when any field 
of the appropriate type is double-clicked, or selected 
and opened from the operating environment or direc- 
tory view Menu via the 'Open* menu item. The 55 
OPEN rule should reflect the most often used func- 
tion that would be applied to a file of the given type, 
sh-expression can be any valid Bourne shell expres- 
sion. Any expression may use multiple lines. Any 
number of expressions may be used, and must be 60 
separated by semicolons (;). The final expression 
should not end with a semicolon. Variable may be 
defined and used as in a Bourne shell script, including 
environment variables. These environment variables 
may be used to refer to the currently selectioned 65 
icons within the operating environment or directory 
view. 

Example: CMD OPEN Swineditor Sfiles 



Syntax: CMD ALTOPEN sh-expression[;sh-expres- 
sion; . . . ; sh-expression] 

Description: The ALTOPEN rule is envoked when any 
file of the appropriate type is double-clicked while 
the ALT key is depressed. The ALTOPEN rule 
provides added functionality for power users, sh- 
expression can be any valid Bourne shell expression. 
Any expression may use multiple lines. Any number 
of expressions may be used, and must be separated by 
semicolons (;)• The final expression should not end 
with a semicolon. Variables may be defined and used 
as in a Bourne shell script, including environment 
variables. These environment variables may be used 
to refer to the currently selectioned icons within the 
operating environment or directory view. 

Example: CMD ALTOPEN make 

1.12 The CMD DROP Rule 

Syntax: CMD DROP sh-expression[; sh-expression; . . . 
; sh-expression] 

Description: The DROP rule is invoked whenever a 
selected (file) icon is "dropped** onto another icon in 
the operating environment or directory view Win- 
dows. When this happens, operating environment 
checks to see if the file type that is being dropped 
upon has a DROP rule to handle the files being 
dropped. In this way, the user can write rules that 
allow one icon to process the contents of other icons 
simply by dragging the icons selected for processing 
onto the top of the target icon (i.e., the one with the 
DROP rule). 

Example: CMD DROP STARGET 5SELECTED 
1.13 CMD PRINT Rule 

Syntax: CMD PRINT sh-expression [;sh-expression; . . . 
;sh -expression] 

Description: The PRINT rule is invoked whenever a 
file of the appropriate type is selected and printed 
using a print menu item form the operating environ- 
ment or directory view menu, sh-cxprcssion can be 
any valid Bourne shell expression. Any expression 
may use multiple lines. Any number of expressions 
may be used, and must be separated by semicolons (;)• 
The final expression should not end with a semicolon. 
Variables may be defined and used as in a bourne 
shell script, including environment variables. These 
environment variables may be used to refer to the 
currently selectioned icons within the operating envi- 
ronment or directory view. The recommended 
method of implementing the PRINT rule is to use the 
print-job routing utility from the operating environ- 
ment. 

Example: OMD PRINT routcprint JLEADER SREST 
1.14 The NEMUCMD Rule 

Syntax: MENUCMD "string** sh-expression [;sh-expres- 
sion; . . . ;sh-expression) 

Description: MENUCMD inserts the menu entry string 
into the operating environment or directory view 
menu if a single file of the appropriate type is se- 
lected, or a group all of the same appropriate type is 
selected. If the menu entry is chosen, the actions 
described by the sh-expressions is performed on each 
of the selected files. 

Example: MENUCMD "Empty Durapster" rro-rf 
SLEADER/* 
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Variables 



Syntax: BOUNDS xO, yO, xl, yl 

Description: xO, yO. xl, yl define, respectively, the 
lower left and upper right corners of the bounding 
rectangle of the coordinate space in which the icon is 
displayed. The values are separated by commas (,)■ 
When the operating environment paints the icon, it 
scales the icon so that its bounds fit just within the 
fixed layout area reserved for it. The aspect ratio of 
the bounding rectangle is preserved. If no BOUNDS 
rule is supplied for a file type's icon, the bounding 
rectangle defaults to 0.0, 0.0, 100.0, 100.0. Referring 
to FIG. 8A, an example of as scaleable icon having 
the bounds -20.0, -20.0, 50.0, 75.0 is shown. 

1.16 The ICON Rule 

Syntax: ICON icon-description-routine 

Description: icon -description -routine is a routine writ- 
ten using the icon description language, detailed be- 
low. The routine can continue foT any number of 
lines. The ICON rule is invoked any time a file of the 
specified type needs to be represented in the operat- 
ing environment or a directory view. The rule is 
evaluated each time the icon is painted by the applica- 
tion that needs it. 



10 
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The following icon status variables are set by the 
operating environment, and may be used in an icon 
description routine: 

current disabled opened located selected 

These variables have values of either true or false. 
They can be used in a conditional statement to alter the 
appearance of an icon when it has been manipulated in 
various ways from the operating environment (see Sec- 
tion 1.18, "Drawing Icons"). 

Other legal C variables may be used in an icon de- 
scription routine without need of a declaration; all vari- 
ables are represented as type float. Any variable name is 
acceptable, provided it does not collide with any of the 
predefined constants, variables or function names in the 
icon description language. 

Functions 

The icon description functions comprise, for the most 
part, a very restricted subset of the C language version 
of a graphic library routine modified for 2-D drawing. 
Table III describes the set of valid icon description 
functions. 

TABLE IIIA 



Function Syntax 



Deft nil ion 



arc (x.y.r.sunang, endang) 



Example: ICON color(iconco)or); 

bgnoutlincpolygon( ); 

venex(0,0); 

vencx(0,6Q); 

venex(40.60); 

vertex(4O,0); 
endoutlinepolygon(oulltnecolor); 



30 



35 



arcf (x.y.r. si ratang. endang) 
betas (color) 



1.17 The Icon Description Language 

The icon description language is a restricted subset of 
the C programming language, including line and poly- 
gon drawing routines from any well-known graphics 
library routine. The description routine for a given icon 
is similar in structure to a C subroutine, but lacking the 
subroutine and variable declarations and the outermost 
enclosing brackets. The valid symbols and functions in 
the icon description language are described below. 

Operators 

The following C language operators may be used in 
an icon description routine: 

+ - •IftlAlft «0O 

The following C language conditional operators may be 
used in an icon description routine: 



&& ll 



<> <- >- 



Constants 

The following logical constants may be used in an 
icon description routine: 



true false 



bgnclosedline ( ) 

bgnline ( ) 
bgnoullinepolygon 

bgnpoint ( ) 

bgn polygon ( > 

. color (n) 
draw (x,y) 

65 endclosedline ( > 



40 



45 



50 



55 



60 



The following icon color constants is described in Sec- 
tion 1.18, "Drawing Icons*'. 



Draw an arc starting at 
icon coordinates x, y, rad- 
ius r. starting at angle star- 
ung. coding at angle endang. 
Angle measures are in 
tenths of degrees. 
Like arc, but Riled with 
the current pen color. 
Like pclos (sec below) but 
uses color for the border 
(outline) color of the poly- 
gon. 

Begin drawing a closed, un- 
filled figure drawn in the 
current pen color. Used in 
conjunction with venex and 
endclosedline. 
Like bgnclosedline, except 
the figure b not closed. 
Used in conjunction with 
vertex and outline. 
Begin drawing a polygon 
filled with the current 
pen color. The polygon is 
outlined with a color spec- 
ified by endoutlinepoiygon. 
Also used in conjunction 
with vertex. 

Begin drawing a scries of 
unconnected points defined 
using calls to vertex. Used 
in conjunction with vertex 
and end point. 
Like bgnoutlinepolygon 
except (he polygon is not 
outlined. Used in conjunc- 
tion with vertex and 
end polygon. 
Set current pen color to 
color index n. 
Draw a line in the current 
color from (he curreni pen 
location to x, y. 
Finishes a closed, unfilled 
figure started with 
bgnc) osedlinc, 
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Function Synui 



Definition 



tod line ( ) 

endoutltnepolygon (color) 

end point ( ) 
endpolygon ( ) 
for 

if (ex pi) cxpr f cite expr ] 
move (x,y) 

pmv (*,y) 

print (eipr of "string'*) 
venci U,y) 



Finishes an open, unfilled figure 

tuned with bfnltne. 

Finishes a filled polygon started 

with bgnouilinepolygon and oui- 

Knn ti with color. 

Finishes a scries of points surtcd 

with bgnpotm. 

Finis ho a filled, unootlincd poly- 
gon scared with bgn polygon. 
Sundard C for- loop. 
Standard C language if-sutfement. 
Move current pen location to x, y. 
Draw a line in the current pen 
color that closes the current poly- 
gon, and fill the polygon with the 
current color. 

Draw the side of a filled polygon 
in the current pen color, from the 
current pen location to *, y. 
Begin a filled polygon it location 
*, y. 

prints the value of the expression 
cxpr or string to stdout; used for 
debugging 

Specifies a coordinate used for 
drawing points, lines, and poly- 
gons by bgn point, bgnline, 
bgn polygon, etc. 
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1.18 Drawing Icons 

Any points, lines, or polygons the user draws will 
"stack" in the order they are drawn, with the most 
recently drawn polygon on top. This concept is used to 
easily achieve drop-shadow effects , by drawing the 
same polygon twice, using different pen colors, and 
offset. 35 

There are three icon color constants are recom- 
mended for standard icon use; iconcolor for drawing 
polygons that make up the "foreground" of the icon, 
outlinecolor for outlining and linework, and shadow- 
color for contrasting drop shadows, iconcolor is panic- 40 
ularly useful, because it automatically changes to the 
calling application's preferred color conventions when 
a given icon is located, disabled, or selected. 

The various icon status variables are used to change 
the appearance of an icon when it is opened, located, 45 
selected, or disabled. The following code fragment 
illustrates how to draw an icon that changes appearance 
when it was opened: 



ICON if (opened) { 

. . . drawing routines for opened icon . . , 

>els*{ 

. . . drawing routines for unopened icon . . 



} 



50 



55 



1.19 Suggested Style Conventions 

The following is a list of suggested style conventions 
to maintain when drawing icons: 

Use the iconcolor, outlinecolor, and shadowcolor as 60 
your icon's typical colors. Be sparing with the use 
of other accenting colors. This will help preserve 
the impact of color when it is needed. 

Create icons that maintain the overall 3-D appear- 
ance that the basic operating environment icons 65 
may have. Most operating environment icons are 
displayed at an angle that emphasizes the third 
dimension. If icons are drawn using the axes de- 



scribed in FIG. 8B, the same effect may be 
achieved. 

The generic executable and generic data file icons 
establish extensible themes that increase the user's 
ability to recognize his own icons. ICON rules 
from the standard system and default FTR files 
may be used as a background for unique represen- 
tations. 

1.20 Compiling FTR Rules 

New FTR rules must be compiled from the FTR 
source files located in a set of directories in /usr/lib/- 
filetype. Any time you add or change FTR rules (or 
print conversion rules) within these subdirectories, you 
must recompile the complete set of .ftr files. This is 
done by performing the following command line se- 
quence: 

su 

cd /usr/lib/filetype 
make 

1.21 Order of Precedence of FTR Files 

FTR source files in the following four directories are 
compiled in the order listed here: 

1. /usr/lib/filetype/local 

2. /usr/lib/filetype/instalJ 

3. /usr/lib/filetype/system 

4. /usr/lib/filetype/default 

Since compiled rules are scanned sequentially by the 
operating environment, a TYPE defined in local will 
override any subsequently defined TYPE with an iden- 
tical type-name. Care should be taken so as not to so 
override important system or default TYPE declara- 
tions. 

Within each directory, separate FTR source files are 
compiled alphabetically. 

1.22 Placement of FTR Rules 

The default and system directories in /usr/lib/- 
filetype are reserved. Developers and users should not 
place their .ftr files in these directories. The install di- 
rectory should be used by applications developers and 
site maintainers for integrating their extensions. The 
local directory may be used by power end-users for 
personal customizations. 

SUMMARY 

Referring now to FIG. 11, the operating environment 
utilizing the file typing rules of the present invention 
provides an iconic interface to a UNIX-based file sys- 
tem, where users can easily find their data and run their 
applications in a visually organized environment. When 
the environment is run, the user is presented with a 
centra] organizing window. This window is" populated 
with a set of graphical icons, providing a summary 
overview of the file system. Path lines connect the icons 
together in a tree structure, revealing the underlying file 
hierarchy. Icon shapes indicate the type of file being 
represented (directory, executable, data file, etc.), and 
each icon is captioned with the name of its correspond- 
ing file. 

Typical file operations such as rename, move, copy, 
and remove can all be accomplished from the environ- 
ment, using the mouse to select and drag icons and to 
invoke pop-up menu commands. Double-clicking an 
icon causes it to "Open", invoking the appropriate ac- 
tion assigned to that file type. For instance, Opening a 
text file's icon brings up the user's preferred text editor 
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on that file. Similarly, Opening an executable file 
launches the selected application, and Opening a direc- 
tory icon brings up a new window, presenting a direc- 
tory view of its contents. The directory view shares the 
same iconic semantics as the environment providing a 5 
visual "cd; pwd; ls M to access the files within a given 
Unix directory. 

The iconic interface within the environment itself is 
implemented via an object-oriented toolkit, developed 
in c+ + . This toolkit provides a standard look and feel 10 
for the environment and a host of related system utili- 
ties, and may be written on top of any well-known 
graphics library routine to support high-performance 
dynamics in the interface. 

In use, the environment interprets the contents of the 15 
file system via a File Typing Engine, which is driven 
from an external set of File Type Rules (FTRs). Each 
file node encountered in the file system is passed to the 
Typing Engine. The characteristics of that file are com- 
pared against each of the FTR criteria in turn, until a 20 
match is found and a Type is assigned. With the as- 
signed Type comes a methodology for displaying and 
operating upon the Typed file. 

When the user selects a file's icon and invokes a com- 
mand (such as Open or Print, for instance), the Typing 25 
comes into play again. The file's Type and the com- 
mand token (e.g. OPEN or PRINT) are used as keys 
inlo the FTR database, returning a corresponding com- 
mand string. This command string is literally passed to 
the Unix shell (sh) for evaluation, using a predefined set 30 
of environment variables to communicate selections, 
preferences, and other handy parameters to the execu- 
tion environment. 

File typing is always conducted on-the-fly, directly 
out of the file system itself, to insure an accurate, cur- 35 



rent representation. However, icon positions and other 
viewing information not intrinsic to the file system itself 
are maintained by the operating environment in its own 
per-user database. This facility provides the user with 
continuity of operation from one session to the next. 

Icons are drawn using a small icon description lan- 
guage imbedded within the FTRs. While all icons may 
be described in 2D coordinates, projective geometry 
guidelines should be followed to establish a consistent 
3D look across the operating environment. An isomet- 
ric approximation is used as shown in FIG. BD, with the 
X and Y axes drawn at a slope of 1 pixel up, 2 pixels 
across, and a Z axis drawn vertically. The color vari- 
able "iconcolor" is preset when the icon is drawn, so 
that it accurately reflects the current state of the icon, 
whether quiet, locate highlighted, or select highlighted. 
Significant areas of an icon should be filled with 'Scon- 
color" to enable the user to readily distinguish the icon's 
state. 

While preferred forms and arrangements have been 
described in illustrating the present invention, it is to be 
understood that various changes in detail and arrange- 
ment may be made without departing from the spirit of 
the present invention or from the scope of the appended 
claims. In particular, while the present invention is 
implemented under one version of the UNIX system, it 
should be especially noted that the principles of the 
present invention are equally applicable and adaptable 
to other versions of the UNIX system, as well as to any 
other computer operating system and equipment. 

Opcodes for the file typing process of the present 
invention are given below. To assist in optimizing com- 
pilers, opcodes have been numbered sequentially so that 
the switch statement can be implemented as a jump 
table. 



OP_ANDi 

OP-ORi 

OP_XORi 

OP ANDANDi. 

OP_ORORi 

OP— COMPLEM E NTi 

OP-BEQi 
OP_BNEi 



OP-BR 



OP_EQEQi 



Bitwise Logical Operator* 

Pops the top two van off the tuck, computes their 

bitwise logical AND, taken as integers. Pushes the 

result as an integer onto the stack. 

Pops the top two van off the suck, computes (heir 

bitwise logical OR. taken as integers. Pushes the 

result as an integer onto the stack. 

Pops the top two van off the suck, computes their 

bitwise logical Exclusive-or. uken as integers. 

Pushes the result as an integer onto the stack. 

Logic*! Opera ters 

Pops the top two van off the stack. IT they are 
both non-zero, taken as integers, then an integer 1 
is pushed onto the suck. Otherwise, an integer zero 
is pushed onto the suck. 

Pops the top two van off the stack. If either of them 
b non-zero, taken as an integer, then an integer 1 
b pushed onto the suck. Otherwise, an integer zero 
is pushed onto the stack. 

Tests whether or not the top var on the suck, taken 
as an integer, is zero. If it is zero, it is replaced 
with an integer one. Otherwise it is replaced with an 
integer zero. 
Branch Operators 

If the top var on the suck, taken as an integer, 

is zero, then the program counter is incremented by 

the signed value of the operand. In any case, the 

suck remains unchanged by OP_ BEQi. 

If the top var on the suck, taken as an integer, 

is non-zero, then the program counter is incremented by 

the signed value of the operand. In any case, the 

suck remains unchanged by OP_BNEi 

The program counter is incremented by the signed value 

of the operand. 

Comparison Operaton 

Pops the top two van off the stack and compares 
them as integers If they are equal, an integer 1 is 
pushed onto the suck. Otherwise, an integer 0 is 
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OP_GEi 

OP-GTi 

OP-LEi 

OP_LTi 

OP-NEi 

OP-MINUSi 
OP_MODi 

OP_PLUSi 

OP_SLASHi 

OP_TIMESi 



OP_LOADa 
OP_LOADi 



OP_POPi 
OP-PUSHSTRING 



OP_STOREi 
OP_ASCII 

OP_DIRCONTAlNS 



OP-LINKCOUNT 



OP-MODE 



pushed onto (he tuck. 

Pops the top two van off tbc suck and compares 
i hero as integers. If the second var popped off 
the stack is greaier than or equal to the first 
v*T, then an integer I a pushed onto the stack. 
Otherwise, a 0 is pushed onto the stack. 
Pops the top two vars off the suck and compares 
them as integers. If the second var popped off 
the suck is greater than the first var, then an 
integer 1 is pushed onto the stack. Otherwise, a 0 is 
pushed onto the suck. 

Pops the top two vars off the stack and compares 

them as integers. If the second vax popped off 

the tuck is less than or equal to the first 

var, then an integer I is pushed onto the suck. 

Otherwise, a 0 is pushed onto the suck. 

Pops tbc lop two vars off the stack and compares 

them as integers. If the second vat popped off 

the luck is less than the first var, then an 

integer I is pushed onto the sUck. Otherwise, a 0 is 

pushed onto the stack. 

Pops the top two van off the tuck and compares 
them as integers. If they are unequal, an integer 1 is 
pushed onto the tuck. Otherwise, an integer 0 is 
pushed onto the suck. 
Arithmetic Operators 

Pops the top two vars off the suck and subtracts the 
first one popped from the second one. as integers. 
The result is pushed onto the suck as an integer. . 
Pops the top two van off the suck and divides the 
second one popped by the first one, as integers. The 
remainder, as defined by the C+ + % function, is pushed 
onto the stack as an integer. 
Pops the top two vars off the suck and adds the 
first one popped to the second one, as integers. 
The result is pushed onto the stack as an integer. 
Pops the top two vars off tbe suck and divides the 
second one popped by the first one, as integers. 
The quotient is pushed onto the stack as an integer. 
Pops the top two vars off the suck and multiplies the 
first one popped limes the second one, as integers. 
The result is pushed onto the stack as an integer. 
Suck Manipulation 

The operand is pushed onto the suck as an integer. 

The integer at the location dspace + the operand is 

pushed as an integer onto the suck. 

The top var is popped from the stack and discarded. 

The address of the string which begins at an offset 

from sspace given by the operand is pushed onto the 

suck. 

The operand is the offset from sspace (inbytes) of a 

character siring. The char set er string is copied into 

malloc'ed memory and the address of this malloc'ed 

memory is pushed onto ihe stack. 

The top var is stored as an integer into the location 

whos address is dspace + the operand. 

File Type Tests 

If the file is a plain file and if the first 512 
bytes of Che file are all prinuble ascti chanters, 
then s 1 H pushed onto the suck as an integer. 
Otherwise a 0 is pushed onto the stack as an integer. 
The top var is popped from the suck and, treated 
as an integer, it is cast into a char *. The null 
terminated string which it points to is first 
prefixed with the character V and then it (V* 
and all) are appended to the CurrentFJeName. If 
this name is 253 or more characters long, then 
a zero is pushed onto the suck as an integer. 
Otherwise , a sut call is performed on this name 
and if successful, a one ts pushed on the stack as 
an integer. If unsuccessful, a rero is pushed on tbc 
suck as an integer. 

Pushed the files link count onto the suck as 
an integer. The link count is determined from the 
file's sLnlink field in itt sut structure. If the 
file can not be suited, then — I is pushed onto the 
suck. 

Pushed the file's mode word onto the stack as 

an integer. The mode word is determined from the file's 

si_modc field in its sut structure. If the file 

can not be suited, then — I is pushed onto the 

suck. 
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OP-SIZE 



OP_TAG 



OP-CHAR 



OP-UCHAR 



OP_SHORT 



OP_USHORT 



OP-LONG 



OP-ULONG 



OP-ENDNAME 



OP-GLOB 



Pushes the file's size in bytes onto the stack is 
an inieger. The size is deiennined from the file's 
st_size field in its sut structure. If the file 
can not be slatted, then - 1 is pushed onto the 
suck. 

If the file is tagged, its tag value is pushed onto 
the stack as an integer. Otherwise. - 1 is pushed 
omo the suck as an integer. 

MIPS executable* and shell scripts may be ugged. The 
ug value is stored in a normally unused Odd is the 
header of the MIPS eiectruble at an ofTsel of 68 
by ies from the beginning of the file. If the file has 
been ugged. the most significant byte at offset 18 
from the suri of the file is set, otherwise it is 
cleared. 

Shell scripts are ugged ir they conform to these 
rules. They must have the character 'PV in their 
fini two posit torn. Their second line musl begin 
with the characters *#Tab* followed by a space 
followed by the ug value as an ascti integer, followed 
by a newline. 
File Reading Opcodes 

The top var is popped from the suck and interpreted 
as an integer indicating a byte offset into the file. 
The byte in the file at this offset is converted from 
a signed char to an int and pushed onto the suck. 
If the file does not contain a byte at the offset or 
if ihe offset is negative or if the file is not a 
plain Ale. then — 1 is pushed on the suck as an 
integer. 

The top var is popped from the stack and interpreted 
as an integer indicating a byte offset into the file. 
The byte in the file at this ofTset is convened from 
an unsigned char to an int and pushed onto the suck. 
If the file does not conuin a byte at the offset or 
if the offset is negative or if the file is not a 
plain file, then — 1 is pushed on the suck as an 
integer. 

The lop var is popped from the suck and interpreted 
as an integer indicating a byte offset into Ihe file. 
The two bytes beginning al this offset in the file are 
treated as a signed short and are converted to an int 
and pushed onto the suck. If the file does not 
conuin two byies at the offset or if the ofTset is 
negative or if (he file is not a plain file, (hen - 1 
is pushed on the suck as an integer. 
The top var is popped from the suck and interpreted 
as an integer indicating a byte offset into the file. 
The (wo bytes beginning al this ofTset in the file arc 
treated as a signed shon and are converted to an int 
and pushed onto the suck. If the file does not 
conuin two byies at the offset or if the offset is 
negative or if the file is not a plain file, then — 1 
is pushed on the suck as an integer. 
The top var is popped from the suck and interpreted 
as an integer indicating a byte offset into the file. 
The four bytes beginning at this ofTset in the file are 
treated u a signed long and arc converted to an int 
and pushed onto the suck. If the file does not 
conuin four bytes at the offset or if the ofTset is 
negative or if the file ts not a plain file, then — 1 
is pushed on the slack as an integer. 
The top var is popped from the suck and interpreted 
as an integer indicating a byte offset into the file. 
The four byies beginning at this offset in the file are 
treated as an unsigned long and are converted to an bit 
and pushed onto the tuck. If the file does not 
conuin four byies at the ofTset or if the offset is 
negative or if the file is not a plain file, then - 1 
is pushed on the suck as an integer. 
Miscellaneous Opcodes 

The top var is popped from the suck and interpreted 
as an integer. If it is non-iero, Executive:run 
returns a one to iu calling procedure. Otherwise it 
returns a zero. 

The top var is popped from the suck and interpreted 
as an integer. Ii is cast into a char pointer. The 
char string ii points to is matched against the base 
name of the file whos type is to be determined. The 
matching is done according to the UNIX C shell glob 
match rules. If the match is successful, a one is 
pushed onto the suck as an integer. Otherwise a 
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OP_LABEL 
OP_PRINTi 



OP_PRINTs 



OP-STRCMP 



OP_STRINC 



zero is pushed onto the stack as an integer. 

No operation is performed by OP_ LABEL 

The top var is popped from the stack and printed as an 

integer to standard out. 

. The top var is popped from thr stack, interpreted as 
an integer and cast into a char The string that 
U pointed to is printed on standard out and its memory 
is free'd. 

The top two vaxs axe popped from the suck, interpreted 
as integers and cast into char •. The strings that 
they point to are compared. If the string pointed to 
by the second argument is less than the string pointed 
to by the first argument, then - ) ts pushed onto the 
suck as an integer. If both strings are equal, then 0 
is pushed onto the stack as an integer. Otherwise 1 is 
pushed onto the stack as an integer. 
The top two variables are popped from the stack and 
interpreted as integers. The first one popped is 
treated as the the length of a ch* rater tiring. The 
second is treated as the byte onset into the file 
of a character string. Space for this character 
string is malloc'ed and the chars are copied into this 
space. A pointer to this space U cast into an integer 
and pushed onto the suck. 
If the string begins or ends before the start of the 
file or after the end of the file then a null string 
is malloced and a pointer to it is cast into an integer 
and pushed onto the stack. 
Execuiive Match Rule class definition 



^define CACHES! ZE 512 
class Executive { 

char Cachc[CACHESlZE]; 

int AlreadyA&ctiTcstcd; 

int AsciiTestResuli; 



// cache of first few bytes in file. 

// 1 if this file has been ASCII tested. 

// The result of the ASCII test. 



public: 



Executive( ); 
-Executive* ); 
void SetFileichar 'filename); 
void UnSetFiW J: 

int runfehar *inst. void •dspace, char •sspace); 
char •CuirentFiieNaine; 
char • Current BaseNamc; 
int Stat table; 



int Cachcable; 

int fd: 

int Openable; 
int Special file; 
struct stm statbuf; 
ini CacheSize: 



// Base name for CurrentFileName. 
// 1 if the stat worked, else 0 
// 1 if ii can be, and therefore is, cached. 
// File descriptor for CurrentFileName 
// 1 if the open worked, else 0 
// 1 if it's not a plain file. 

// No. of bytes really in the cache 



Executive Match Rule vir structur e 
The var structure is a typedef for a struci which can hold ints floats or up 



to 4 characters. 



typedef union { 

char c|4] 
int integer; 
float fix; 

}var; 



Name 



Type 



Executive Match Rule Class Variables 
Purpose 



CurrentFileName char • 
Current Base Name char * 
Special file int 



Openable 



int 



Statublc 



statbuf 



Holds the full path name of the file wbos 
type is to be determined. 
Holds the last level of the full path name of 
the file whos type is to be determined. 
Set to 1 tf a fik U not a plain unix file. 
(Eg., a device node, a fifo, . . . etc). Set 
to 0 otherwise. 

Set to 1 if the file has been opened. Set to 
zero if the file has not been opened. Special 
files are never opened. If a file does not 
have read permission set, then it can not 
be opened - 

The file descriptor of the file to whos type 
is to be determined. If Openable « «= 0, then 
fd is unused. 

Set to 1 if a Unix stat procedure call on the 
file was successful. Set to 0 otherwise. If 
successful, the result of the slat call is 
stored in the structure statbuf. below. 
If the stat call on the file was successful, 
the result ts stored in statbuf, a UNIX stat 
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Cachcable 
Cache 

CACHESIZE 
CacheSize 



char[ ] 

0 define 
int 



AlreadyAsciiTcsted int 
AsctiTcst Result int 



structure. Subsequent!)', if any of the cases 
in Execuiive:run need to make decisions based 
on stat information, they can get the 
in format ton from statbuf and avoud the cost 
of caJhng sial. 

Set to I if some of the contents of the Hie 

are stored in a cache in order to reduce the 

number of references to the file. 

If Cache-able — •» 1 then Cache contains the 

contents of the cache. Otherwise Cache is 

unused. 

The size, in bytes, of the cache 312 bytes 
works well. 

The number of bytes actually held in the cache. 

CacheSize may be less than CACHESIZE because 

the file contains less than CACHESIZE bytes. 

When Cachcable - m 0, CacheSize is unused. 

Set to 1 if the OP_ASCII case is perform ed 

in Executiverrun. Set to 0 otherwise. 

Set to the result of the OP_-ASCII case in 

Executive:run. If AlreadyAsciiTesied - * 0, 

then AsciiTcst Result is unused. 

AscuTest Result is used to eliminate the cost of 

repeatedly performing the Op_ASCII case 

because if it is repeated, the result can 

be fetched here, instead of being fully 

recomputed. 



Executive:run Match Rule Variable s 
This table lists the variables in Executive: run which are used for processing 
match rule programs. 

Name Type Purpose 

pcO parameter, char* Points to the first stack machine instruction 

of the match rule program. 

dspace parameter, void* Points to the numeric constants of the match 

rule program. 

sspace parameter, char* Points to the string constants of the match 

rule program. 

pc char* The program counter for the suck machine, 

stackp var* The stack poinier for the suck machine, 

stack vir[)000] The stack for the suck machine. 1000 elements 

seems to be piemy. 

af,bl\cf,df.ef float These are temporary variables used throughout 

E*ecuiive:njn to hold intermediate results 
within a case. To make Executive:™ n simples 
to analyze, The values they hold are never 
re-used after the case thai they are used in 
has been exited. 

ai.bi.i int These arc temporary variables used throughout 

ExecutivcTun to hold intermediate results 
within a case. To make Execuiive:run simples 
to analyze. The values they hold are never 
re- used after the case that they are used in 
has been exited. 

operand var The operand of the current infraction. It is 

set up by ihe GETOPERAND procedre in the c 
for opcodes which have operands. 

chanmp char Temporary variable used for conversions into 

type char. 

shorttmp short Temporary variable used for conversions into 

type short. 

longtmp long Temporary variable used for conversions into 

type long. 

ucbarttnp unsigned char Temporary variable used for conversions into 

type unsigned char. 

ushorttmp unsigned short Temporary variable used for conversions into 

type unsigned short. 

u longtmp unsigned long Temporary variable used for conversions into 

type unsigned short. 

p,p2 char * These are temporary variables used throughout 

Eaecutivetrtin to hold intermediate results 
within a case. To make Executivexun simples 
to analyze. The values they hold are never 
re-used after the case that they are used in 
has been exited. 

status int Temporary variable used throughout 

Executive :run to bold the return codes from 
procedure calls. 

Searchrilename char[237] A place to assemble the full path name of the 

file to search for in the 
OP-DIRCONTAINS case. 

dircontainsbuf struct tiai The UNIX stat structure returned from the sut 
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system call in the OP_DlR CONTAINS case. 



Opcodes for rendering icons ire 
OP-ANDf 

OP-ORf 

OP_XORf 

OP_ANDANDf 

OP_ORORf 

OP_COMPLEMENTf 



OP-BEQf 



OP_BNEf 



OP_BR 



OP_EQEQf 



OP_G£f 



OP_GTf 



OP-LEf 



OP_LTf 



OP_NEf 



OP_MIMUSf 
OP_MODf 



OP_PLUSf 
OP.SLASHf 



given below: 

Bitwise Logical Operators 

Pops the top two van off the stack. They axe both 
treated as floats and convened to integers and bitwise 
anded. The result is pushed onto the suck as a float. 
Pops the top two vars ofT the stack. They are both 
treated as floats and convened to integers and bitwise 
orcd. The result b pushed onto the stack as a float. 
Pops (he top two van ofT the stack. They are both 
treated as floats and convened to integers and bitwise 
exclusive ored. The result is pushed onto the stack 
as a float. 
Logical Operators 

Pops the top two van ofT the stack. If they axe 
both non-zero, taken as floats, then a float one 
is pushed onto the suck. Otherwise, a float zero 
is pushed onto the suck. 

Pops the top two vars off tbc stack. If cither of them 
is non-zero, uken as a float, then a float one 
is pushed onto the suck. Otherwise, a float zero 
is pushed onto the suck. 

Tests whether or not the top var on the suck, uken 
as a float, b zero. If it is zero, it is replaced 
with a float one. Otherwise it is replaced with a 
float zero. 
Branch Operators 

If the top var on the suck, uken as a float 

is zero, then the program counter is incremented by 

the signed value of the operand. In any case, the 

slack remains unchanged by OP_BEQi 

If the top var on the suck, uken as a float. 

is non-zero, then the program counter is incremented by 

the signed value of (he operand. In any case, the 

stack remains unchanged by OP— BNEi. 

The program counter is incremented by the signed value 

of the operand. 

Comparison Operators 

Pops the top two vars off the suck and compares 
ihem as floats. If they are equal, a float 1 is 
pushed onto the stack. Otherwise, a float 0 U 
pushed onto the suck. 

Pops the top two vars off the suck and compares 
them as floats. If the second var popped off 
the suck is greater than or equal to the first 
var, then an floats 1 is pushed onto the suck. 
Otherwise, a float 0 is pushed onto the suck. 
Pops the top two vars off the suck and compares 
them as floats. If the second var popped off 
the stack is greater lhan the first var, then an 
float 1 is pushed onto the suck. Otherwise, float 0 
is pushed onto the suck. 

Pops the top two vars off the stack and compares 
them as floats. If the second var popped off 
the suck is less than or equal to the first 
var. then a float 1 b pushed onto the stack. 
Otherwise, a float 0 b pushed onto the stack. 
Pops the top two van off the suck and compares 
then as floats. If the second var popped ofT 
the stack b less than the first var, then an 
float 1 b pushed onto the suck. Otherwise, a float 
0 b pushed onto the suck. 
Pops the top two van off the suck and com pares 
them as floats. If they are unequal, an float 1 is 
pushed onto the suck. Otherwise, a float 0 b 
pushed onto the suck. 
Arithmetic Operators 

Pops the top two van off the suck and subtracts the 

first one popped from the second one, as floats. 

The result b pushed onto the stack as a float. 

Pops the top two van off the suck. They are both 

treated as floats and convened to istegen and 

their remainder upon division b computed according to 

the rules of the C-f + % operator. The result b pushed 

onto the suck as a float. 

Pops the top two van off the suck and adds the 

first one popped io the second one, as floats. 

The result b pushed onto the suck as a float. 

Pops the top two van off the suck and divides the 

second one popped by the first one. as floats. 

The quotient is pushed onto the suck as a float. 
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OP-TIM ESf 



OP_LOADCf 
OP-LOADf 

OP_POPf 
OP-PUSHSTRING 



OP-STOREf 

OP-ARC 

endang 
surung 

y 



OP-ARCF 

endang 
starting 
radius 



Pops the I op two van ofT the stack and multiplies the 
first one popped times the second one. as floats. 
The restth is pushed onto the suck as a float. 
Stack Manipulation 

The operand is pushed onto the stack as a float. 

The float at the location dspace 4 the operand is 

pushed as a float onto the suck. 

The top var b popped from the suck and discarded. 

The address or the string which begins at an offset 

from sspace given by the operand is pushed onto the 

suck. 

The operand is the ofTset from sspace (in bytes) of a 
character string. The character string is copied into 
malloc'ed memory and the add reu of this malloc'ed 
memory is pushed onto the suck. 
The top var is stored as a float into the location 
whos address is dspace + the operand. 
Graphics Operations 

Draws an arc of a circle. Five vars are popped off 
the suck and interpreted as floats. They are (in 
order of being popped): 

the measure of the end angle of the arc. The end angle 

of the arc is measured from the positive x-axis. 

the measure of the start angle of the ere. The surt 

angle of the arc is measured from the positive x-axis, 

the length of the radius of the arc. The radius of 

the arc is the radius of the circle thai would contain the 

arc. 

the y coordinate of the center of the arc. The center 

of the arc is the center or the circle that would conuin the 

arc, r 

the x coordinate of the center of the arc. The cenler 

of the arc is ihe center of the circle thai would conuin the 

arc. 

Draws a solid filled arc of a circle. Five vars are 
popped off the suck and interpreted as floats. They, 
are (in order of being popped): 

the measure of the end angle of (he arc. The end angle 

or the arc is measured from ihe positive x>axis: 

the measure of the start angle of the arc. The start 

angle of the arc is measured from the positive l-axis. 

the length of the radius of ihe arc. The radius of 

the arc is the radius of the circle that would conuin the 

arc. 

the y coordinate or the center of the arc. The center 

of the arc is the center of the circle that would contain the 



OP_BCLOS 

OP_BGN 
OP-COLOR 

OP-DRAW 

OP-ENDCLOSEDLINE 
OP-ENDLINE 

OP_ENDOUTLINE POLYGON 

OP_ENDPOINT 
OP^END POLYGON 
OP-1CONCOLOR 

OP—MOVE 



the x coordinate of the center of (he arc. The center 

of the arc is the center of the circle that would conuin (be 

arc. 

Pops one var off the suck and interprets it as a float. It 
is used as an border color. The polygon described by the 
vertice list is filled in the curreni color and outlined 
by the border color. Then the vertice lisl is cleared. 
Clears the vertice list. 

Pops one var off the suck and interprets it as a float. The 
current drawing color is set to this value. 
Fops two vars off the suck and interprets them as floats. The 
first one popped is laken as a y coordinate and the second one 
is taken as the x coordinate A line is drawn from the 
current graphics position to (x,y). 

The border of the polygon described by the vertice list is 
drawn in the current color. The vertice list is cleared. 
A aeries of lines are drawn, in order, in the current color 
which conned the vertices of the polygon described by the 
venice list. No line is drawn which connects the last 
venice with the first. The venice list is cleared. 
Pops one var off the stack and interprets it as a 
float. It is used as an border color. The polygon described 
by the venice list is filled in Ihe current color and outlined 
by the border color. Then the venice list b cleared. 
The vertices in the venice lists are drawn as single pixel 
points in the current color. The vertice list s cleared. 
The (he polygon described by the vertice fast is filled in the 
current color. The vertice list is cleared. 
The recommended icon color is pushed onto the suck as a 
float. 

(The recommended icon color is defined by calline the pro- 
cedure Exec uti versicolors). 

Pops two vars off the stack and interprets them as Doits. The 
first one popped is uken as a y coordinate and the second one 
is uken as the x coordinate. The current graphics position is 
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OP-OLTX1NECOLOR 



OP-PCLOS 



OP-PDR 



OP-PMV 



OP-SHADOWCOLOR 



O P_ST ATECURR ENT 



OP-STATEDISABLED 



OP_STATELOCATED 



OP-STATEOPENED 



OP_ST ATESELECTED 



OP_VERTEX 



OP_ENDPROG 
OP_LABEL 
OP_PR INTf 

OP_PRINTs 



set to.(x.y) and the Venice list it cleared. 
The recommended outline color is pushed onto the suck as a 
float. (The recommended icon color b defined by calline the 
procedure Executive .tetcolon). 

The the polygon described by the Venice tut b tilled in the 
current color. The vertice list is cleared 
Pops two van ofT the stack and interprets them as floats. The 
first one popped is taken as a y coordinate and the second one 
b taken as the a coordinate. If the vertice list contains 
less than 255 vertices then (x,y) is then added to it as the 
last vertice. 

Pops two van off the ttack and interprets them as floats. The 

first one popped is taken as a y coordinate and the second one 

is taken as the a coordinate. The vertice list b cleared and 

(x.y) is then added to it as the first vertice. 

The recommended shadow color b pushed onto the stack as a 

float. (The recommended icon color is defined by calline the 

procedure Exec utiverset colon). 

The current state is pushed onto the stack as a float 

(The curreni state b defined by calline the procedure 

Executivc:sctsuic). 

The disabled state is pushed onto the stack as a float. 
(The disabled stale b defined by calline the procedure 
Executive:setstaie). 

The located state b pushed onto the stack as a float 
(The located state is defined by calline the procedure 
Exccutive:sctsuic). 

The opened state is pushed onto the suck as a float. 
(The opened sute b defined by calline the procedure 
Executive:setsute). 

The selected state b pushed onio the suck as a float. 
(The selected siate is defined by calline the procedure 
Executivc:setsute). 

Pops two vars ofT the suck and interprets them as floats. The 
first one popped is taken as a y coordinate and the second one 
is taken as the x coordinate. If the vertice list contains 
less than 255 vertices then (x,y) is then added to it as the 
lasi vertice. 

Miscellaneous Opcodes 

No operation is performed by OP—LABEL. 

The top var b popped from the suck, interpreted as 

a floai printed to standard output. 

The top var is popped from the suck, interpreted as 

an integer and cast into a char * The string that 

b pointed to is printed on sundan out and its memory 

b free'd. 

Executive Icon Rule class definition 



class Executive { 

float IconOpcned State; 
float IconDisabledSute: 
float IconLocated State; 
float IconSeleclcdSutc; 
float IconCurrentSute; 
float IconShadowcoior; 
float Iconlconcolor; 
float IconOutlinccolor; 



// Icon sute variables. 



// Icon color variables. 



public: 



); 



Executive( ); 
—Executive^ ); 

void sctsute(int,int,int,int,tnt); 

void set colors(in t,in tint); 

tnt run(char *inst, void *dspacc, char *sspacc); 



Executive Icon Rule var structure 



The var siructurc is a lypedef for a struct which < 
to 4 characters. 

typedef union { 

char c(4J ; 
int integer; 
float flt; 

}var; 



i bold ints floats or up 



Name 



Type 



Executive Icon Rule Class Variable s 
Purpose 



IconOpencdSute float Pushed onto the suck by the OP_ST ATEO PEN ED 

case. Set by the Executive rseteolon procedure 
call. 

IconDisabledSute float Pushed onto the suck by the OP_STA TED JSA BLED 

case. Set by the Executives colors procedure 
call. 
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-continued 



IconLocated State float Pushed onto the stack by the OP_ST ATE LOCATED 

case. Set by the Executive se (colors procedure 
call. 

iconSeleciedSiaic float Pushed onlo the suck by the OP— STATES ELECTED 

case. Set by the Executive setcolort procedure 
call 

IconCurTcmSute float Pushed onto the stack by the OP_STATECURRENT 

case. Set by the Executi versicolors procedure 
call. 

IconShadowcolor float Pushed onto the suck by the OP-SHADOWCOLOR 

case. Set by the Executive setcotore procedure 
call. 

Iconlconcolor float Pushed onto the suck by the OP_ I CON COLOR 

case. Set by the Executive act colors procedure 
call. 

IconOuilinecolor float Pushed onto the suck by the OP_OUTLJNECOLOR 

case. Set by the Executive set colors procedure 
call. 



Execuiive:nin Match Rule Variables 



This uble lists the variables in Executive:run which are used for processing 
icon rule programs. 

Name Type Purpose 



pcO 


parameters har* 


Points to the first suck machine instruction 


of the match rule program. 


dspace 


para meter, void* 


Points to the numeric constants of the match 






rule program. 


sspace 


parameter.char* 


Points to the string constants of the match 




rule program. 


PC 


char» 


The program counter for the stack machine. 


stack p 


var" 


The stack pointer for the stack machine. 


tuck 


var[IO0O] 


The stack for the stack machine. 1000 elements 




seems to be plenty. 


af.bf.cf.df.ef 


float 


These are temporary variables used throughout 




Executive :run to hold intermediate results 






within a case. To make Executive: run simples 






to analyze. The values they hold are never 






re-used after the case thai they are used in 






has been exited. 


ai.bi.i 


int 


These are lemporary variables used throughout 






Executive:run to hold intermediate results 






uhhin a case. To make Executive :run simples 






to analyze, The values they hold are never 






re-used after the case that ihey are used in 






has been exited. 


operand 


var 


The operand of the current instruction. It is 




set up by the GETOPERAND procedre in the cases 






for opcodes which have operands. 


pos 


struct { 


Pos is the venice list. It is used for 


float x,y; 


assembling together vertices as supplied 




) [256]. 


by OP-PMV. OP-FDR and OP_VERTEX. 


nverts 


int 


The number of vertices in the venice list. 


cx,cy 


float 


The x and y coordinates of the current graphics 




position. 


curcotor 


int 


The current graphics color. 



We claim: 50 

1. The method of characterizing files in a computer 
system having an operating and file management sys- 
tem, said method comprising the following steps: 

deriving the file typing rules according to a prese- 
lected command structure, each of said file typing 55 
rules including a rule key; and an expression fol- 
lowing said rule key defining said file typing rule; 

defining a plurality of file types to produce defined 
file types, said defined file types stored in a file type 
file; 60 

defining a plurality of type declarations in a file type 
file, each of said plurality of type declarations asso- 
ciated with and identifying a unique file type; 

defining a plurality of file typing rule sets, each of 
said file typing rule sets associated with at least one 65 
of said defined file types, each of said plurality of 
file typing rule sets further including one of said 
plurality of type declarations identifying said asso- 



ciated file type, at least one file typing rule defining 
file functions executable by a user; 
compiling said file typing rules to produce compiled 

file typing rules; 
storing said compiled file typing rules; and 
characterizing files according to said file typing rules 
in response to commands received from said oper- 
ating and file management system. 

2. The method as in claim 1 further comprising the 
step of defining each of said plurality of file typing rule 
sets to include at least one file typing rule defining the 
format of said unique file type associated therewith. 

3. The method as in claim 1 further comprising the 
step of defining each of said plurality of file typing rule 
sets to include at least one match rule, executing said 
match rule in response to a user input, said match rule 
assigning a defined file type to a file. 

4. The method as in claim 3 further comprising the 
step of testing a file for a single distinguishing character- 
istic of the associated file type for said match rule, said 
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match rule evaluates to true if each of said match func- match rule of each of said file typing rule sets in the 
tions is true when compared to the corresponding dis- order of said predetermined sequence* the testing of said 
tinguishing characteristics of a file under test, a file type file under test terminating as soon as a match rule en- 
being assigned to a file under test if said associated countered in said sequence evaluates as true, 
match rule evaluates to true. 5 11. Apparatus as in claim 9 wherein said match rule 

5. The method of claim 4 further comprising the step forms a logical expression comprising a set of match 
of arranging said match functions in a predetermined functions conjoined by logical operators, each of said 
sequence from the left, such that the more likely a match functions testing a Hie for a single distinguishing 
match function is to be false, when compared to the characteristic of the associated file type for said match 
corresponding distinguishing characteristic of a file 10 rule, said match rule evaluates to true if each of said 
under test, the further to the left the match function will match functions is true when compared to the corre- 
be in said predetermined sequence. sponding distinguishing characteristics of a file under 

6. The method of claim 5 further comprising the step test, a file type being assigned to a file under test if said 
of arranging said plurality of file typing rule sets in a associated match rule evaluates to true, 
predetermined sequence such that a file under test is IS 12. Apparatus as in claim 11 wherein said match func- 
compared with the match rule of each of said file typing tions forming said logical expression are arranged in a 
rule sets in the order of said predetermined sequence, predetermined sequence from the left, the more likely a 
the testing of said file under test terminating as soon as match function is to be false, when compared to the 
a match rule encountered in said sequence evaluates as corresponding distinguishing characteristic of a file 
true. 20 under test, the further to the left the match function will 

7. Apparatus for characterizing files in a computer be in said predetermined sequence. 

system having an operating and file management sys- 13. Apparatus as in claim 7 wherein said computer 

tern, said apparatus comprising: system further includes: 
file typing means for deriving file typing rules ac* a graphical description language for generating a 
cording to the preselected command structure, 25 plurality of icons providing a graphical user inter- 
each of said file typing rules including a rule key; face representing operations and functions of said 
and an expression following said rule key defining computer system; and 

said file typing rule; said file typing means includes control means for 

said file typing means including a file type file, means controlling the appearance and functionality of 

for defining a plurality of file types to produce JO said icons. 

defined file types, said defined file types stored in 14. Apparatus as in claim 13 wherein said graphical 
said file type file, means for defining a plurality of . user interface provides a visual overview of the file 
type declarations in a file type file, each of said management system utilized by said computer system, 
plurality of type declarations associated with and 15. Apparatus as in claim 13 wherein said graphical 
identifying a unique file type; 35 user interface provides a visual overview of file man- 
said file typing means further including means for agement functions accessible by a user via an input 
defining a plurality of file typing rule sets, each of means. 

said file typing rule sets associated with at least one 16. Apparatus as in claim 13 wherein said file typing 

of said defined file types, each of said plurality of rules include a plurality of icon bounds rules, each of 

file typing rule sets further including one of said 40 said icon bounds rules associated with a different icon, 

plurality of type declarations identifying said asso- each of said icon bounds rules defining a selectable 

ciated file type, at least one file typing rule defining coordinate space in which said associated icon is dis- 

file functions executable by a user; played and scales said associated icon consistent with 

compiling means coupled to said file typing means for said defined coordinate space, 

compiling said file typing rules to produce com- 45 17. Apparatus as in claim 13 wherein said graphical 

piled file typing rules; description language includes selectable instruction sets 

storage means coupled to said compiling means for for defining and generating said icons having selectable 

storing said compiled file typing rules; and size, shape and color. 

processing means coupled to said storage means for 18. Apparatus as in claim 17 wherein said selectable 
characterizing files according to said file typing 50 instruction sets include routines defining icon fore- 
rules in response to commands received from said ground coloring, icon outlining color and shadow con- 
operating and file management system. trast. 

8. Apparatus as in claim 7 wherein each of said plural- 19. Apparatus as in claim 13 wherein said plurality of 
ity of file typing rule sets further comprises at least one icons are organized in a tree structure representing a 
file typing rule defining the format of said unique file 55 hierarchy of said file system. 

type associated therewith. 20. Apparatus as in claim 19 wherein the shape of the 

9. Apparatus as in claim 7 wherein each of said plural- visual image representing an icon is representative of 
ity of file typing rule sets further comprises at least one said unique file type associated therewith. 

match rule, said means for determining the file type of a 21. Apparatus as in claim 19 wherein a number of file 

file responsive to a user input for executing said match 60 operations are defined, each of said file operations asso* 

rule, said match rule assigning a defined file type to a ciated with at least one of said icons, 

file. 22. Apparatus as in claim 21 where the shape of the 

10. Apparatus as in claim 9 wherein said plurality of visual image representing an icon is representative of 
file typing rule sets are arranged in a predetermined said defined file operation associated therewith, 
sequence such that a file under test is compared with the 65 • • • * • 
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